ServiceNow Automated Test Framework: Security and Access Design

Access Model for Test Framework

Automated Test Framework records test execution, results, and evidence. Access should be role-based. Test developers create and modify tests. Test runners execute tests and capture results. Quality leads approve test runs and review results. Auditors can view but not modify.

Distinguish between test definition access and test execution access. A developer can modify a test definition. A test executor can run a test but may not modify it. Quality lead can view results and make decisions. Different roles, different permissions.

Test data access requires extra care. Tests often use sensitive data—passwords, API keys, PII. Access to test data should be restricted to those who need it. Use masked data where possible. Store sensitive data securely, not in test definitions.

Least Privilege for Test Access

Grant test developers access to create and modify tests in their area only. A developer testing payment module should not access HR module tests. Query-based ACLs can restrict by module or business area.

Grant test executors ability to run tests and view results, but not modify test definitions. If a test executor could modify tests, they could hide failures or sabotage quality. Separate creation from execution.

Grant test administrators access to maintain test framework configuration—test environments, test data, scheduling. Administrators have broad access but should be trustworthy. Regular review of admin access is important.

Segregation of Duties

Test developer and test reviewer should be different people. Developer writes test, reviewer approves before the test is active. This prevents bad tests from being deployed. However, in small teams, one person may do both. If so, document the exception and require leadership approval.

Test executor and test result interpreter should ideally be different. Executor runs test and captures results. Interpreter reviews results and decides if they are pass or fail, acceptable or concerning. Separating these roles prevents bias.

Test framework administrator and test framework user should be different. Administrator maintains framework tools and configuration. Users use framework to write and run tests. If same person does both, they have too much power and too many conflicts of interest.

Test Data Security

Test data often includes sensitive information—production data clones, customer information, or credentials. Secure test data carefully. Encrypt at rest. Encrypt in transit. Restrict who can access test data.

Use masked or fake data instead of real data when possible. A test can verify credit card processing without using real credit card numbers. Fake data is easier to secure and reduces risk if it leaks.

Purge test data regularly. Do not keep it longer than needed. If test data is months old, delete it. Old data accumulates and increases risk. Regular purge keeps data footprint minimal.

Audit Evidence for Test Execution

Maintain immutable record of test execution. Who ran the test? When? What version of the test? What was the result? Audit trail should not be modifiable by test executors. Only framework admins should be able to audit log entries, and only to add—not delete or modify.

Capture test results with evidence. For UI tests, capture screenshots. For API tests, capture request and response. Evidence shows exactly what the test did and what happened. Evidence is valuable for investigating test failures or for compliance audits.

Maintain test definition version history. If a test is modified, prior versions should be preserved. You should be able to see what changed between versions. Version history helps debug test issues.

Review Cycle for Access

Review test framework access quarterly. Confirm that test developers still need access to the modules they test. Confirm that test executors still need to run tests. Confirm that test data access is appropriate.

Review access when employees change roles. If a developer moves from payment team to HR team, update test module access. Do not leave them with access to payment module tests.

Quarterly review should also check for orphaned test definitions—tests no longer in use that nobody runs. Delete orphaned tests and free up test data. This keeps test framework clean and secure.

Compliance and Audit Readiness

Automated Test Framework execution history is audit evidence. If regulatory auditors ask “how do you know the system is working correctly?”, you produce test results showing systematic validation. Maintain good records.

Traceability is important. A defect in production should be traced back to test. Did test catch it? Why did it pass testing? Was test inadequate? Traceability from production issue to test helps prevent recurrence.

Some regulations require documented testing evidence. Maintain reports showing what was tested, when, and results. These reports satisfy audit requirements. Set up automated test reporting so reports are always available.

Choosing which identity each test runs as

The identity a test runs under decides what the test can see and change, and it is a decision often made by accident. A suite built during a busy sprint tends to run as whichever user the author was logged in as, often one with broad administrative rights, and that choice then sets the baseline for every later run. The right starting point is to decide the identity deliberately, one suite at a time, against the least privilege the test needs to prove its point.

ATF can act as another user through impersonation steps. That is useful for proving that a restricted user can or cannot complete a task, but it also means the account running the suite must be trusted to switch identity. Treat impersonation as a privileged capability: limit which accounts can run suites that impersonate, and review those suites in the same way as privileged scripts.

Keeping credentials out of test definitions

A test that types a password into a step is a credential leak waiting to happen. The definition is copied into exports, shared between teams and sometimes pasted into support tickets. Keep every secret out of the step body. Reference it from the platform’s credential store and name it there. Where the value is only needed to log in as a test persona, consider whether the persona can be impersonated instead, which removes the need for a password entirely.

Rotation matters as much as storage. A pipeline credential that has not changed for a long time is a standing risk, because anyone who once saw it still has access. Set a rotation schedule the security team agrees to, and make the rotation a step in the pipeline runbook so it is not forgotten.

A review sequence for new or changed suites

Access review is easier when it is part of the change process rather than an annual audit. The sequence below can be run by a second person before a suite is allowed to run on a shared instance.

1. Confirm the identity each test uses and why that identity is the least privileged one that works.
2. Check that no step contains a literal secret, and that every secret is referenced from the credential store.
3. Look for impersonation steps and confirm the running account is permitted to use them.
4. Confirm that cleanup steps only remove records the suite created, identified by its own run tag, and never by broad criteria.
5. Record the reviewer, the date and the identities approved, in the same change record that introduced the suite.

Instance controls that protect the test results themselves

Access design is not only about who can run tests. It also covers who can alter the evidence. If a tester can edit a stored result after the fact, the gate loses its value. Keep result records writable only by the framework’s own processes, and restrict edits to test definitions to the stewards of those suites. Where your instance logs changes to these records, check that the log is reviewed by someone outside the team that owns the suites.

Network and source restrictions are another layer. Where the platform supports limiting which addresses can start suites through its API, use it for the pipeline account, so a stolen token cannot be used from an unknown machine. Confirm the restriction actually applies during a test call from outside the approved range before relying on it.

Checklist for the access side of a test program

• Every suite has a recorded identity and a reason for it.
• No suite stores a literal password, token or key in its steps.
• Impersonating suites are listed, and the accounts allowed to run them are short and reviewed.
• Pipeline credentials have an owner, a rotation date and a documented revocation step.
• Result records and test definitions have separate edit rights, and changes to either are logged.

Questions about access that come up after go-live

Can we use one shared test user for everything to keep things simple?

It is simpler to set up and much harder to reason about. A shared user with broad rights makes it hard to prove that a restricted role was denied an action, because the test never ran as that role. Use a few persona accounts with narrow roles, and accept the extra setup as the price of meaningful denial tests.

What about tests that need to create accounts or change roles?

Keep those suites on a non-production instance, run them under an account with a narrow remit for that purpose, and never allow them to run against a production-like instance that other teams depend on. Their evidence is valuable, but the blast radius of an error is large.

How do we handle a suite whose identity was over-privileged for years?

Re-run the suite under a narrower identity in a non-production environment and see which steps fail. Each failure either shows a genuine permission the test needs, which should be granted explicitly and recorded, or a step that was relying on privilege it should not have had.

Should auditors be given access to the test framework?

They should be able to read results and definitions without being able to edit them. Read-only access gives them the evidence they need, and keeps the separation between the people who write tests and the people who attest to them.

The instance security and access control best practices set the wider platform rules that test accounts sit inside. For the review cycle, the access controls review article describes how to inspect permissions, while the audit trail article describes what a reviewer should expect to find in the logs. The roles and RACI page sets out who holds each role that these identities belong to.