Test Script: Security and Access Control

This is a ready-to-use security and access control test script. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and run it under an approved validation plan or protocol. A worked filled specimen follows the template so you can see how a completed version reads. Security tests are contemporaneous GxP evidence: write each actual result as you observe it, in ink or in the validated tool, capture the exact message text and screen state, and never reconstruct an outcome later. Verify each cited regulation against the current source before you rely on it.

What this script proves, and what it does not

This script demonstrates that the system enforces who can do what, and just as importantly that it blocks who should not. It verifies the access control configuration the User Requirements Specification and the system security design call for: that roles grant only the privileges they should (least privilege), that two incompatible duties cannot be held or exercised by one account (segregation of duties), that password complexity and account lockout behave as configured, and that the system refuses unauthorized actions, expired credentials, and disabled accounts. Half of a security script is negative testing: confirming that a forbidden action is actually stopped, with the system’s own denial message as the evidence. A test that only shows the allowed path passing has tested nothing about security.

This script does not configure the access model and does not replace the user access review or the periodic re-qualification of accounts. The access model lives in the configuration specification and the role-privilege matrix; the ongoing review lives in your access management procedure. This script proves the configured model behaves as designed at the moment of qualification.

Document control header

1. Requirements traced

State exactly which requirements this script verifies, so the traceability matrix links each requirement to its evidence in both directions. Every requirement listed must be exercised by at least one numbered step in section 7.

2. Objective

In one or two sentences, state what passing this script demonstrates. Example: this script verifies that the system enforces role-based least privilege, the configured password and lockout policy, and segregation of duties, and that it refuses authentication and privileged actions from disabled accounts, expired credentials, and under-privileged roles.

<<FILL: objective>>

3. Access model under test

Attach or summarize the role-privilege matrix being verified. The test steps in section 7 are derived from this table, one role at a time, and must cover both the privileges each role should have and the privileges it must not.

Note the deliberate split in the last row: the administrator who manages accounts should not also be able to create or approve GxP records, and the people who create and approve records should not be able to grant themselves privileges. Where one person must hold both for business reasons, that combination is a documented, justified exception with a compensating control (for example independent audit trail review of administrator actions), not a silent grant.

4. Prerequisites

List everything that must be true before execution starts. If any prerequisite is not met, do not execute; record the gap as a deviation and stop.

5. Configured policy values under test

Record the configured values once here, then verify them by behavior in section 7. These are the numbers the steps challenge; set them from your configuration specification, not from a default.

6. Execution conventions

Read these before executing, then follow them for every step.

• Record each actual result contemporaneously, as you observe it. Do not pre-fill, do not batch at the end.
• For negative tests, the actual result must capture the system’s own denial: the exact error or authorization message text, plus confirmation that the forbidden action did not take effect (no record created, no privilege gained, no login granted). “Access denied as expected” without the message text is weak evidence.
• “Meets expected result” is not an actual result. Write the value, message, or screen state you saw.
• Use one unambiguous mark for pass or fail. A blank cell is incomplete, not a pass.
• Capture objective evidence (screenshot, log export) for every step whose pass depends on a system output or denial, and give that evidence a unique reference recorded in the step.
• Where a step changes account state (lock, disable, age a password), record the starting state and restore it, or note that cleanup is handled in section 12.
• The moment any step does not meet its expected result, mark it Fail, stop if instructed, and open a deviation per section 10. A privilege that should be denied but is allowed is a critical finding, not a minor one.

7. Test steps

For each step give the action, the precise expected result, the actual result as observed, pass or fail, and the evidence reference. Expected results are written before execution and must be specific enough that two people would agree on whether they were met. Group the steps by control area so coverage is visible.

7.1 Role-based access and least privilege

7.2 Password and lockout policy

7.3 Segregation of duties

7.4 Disabled, expired, and unauthorized access

Add or remove rows so every requirement in section 1 and every role and denied privilege in section 3 is exercised. Number steps continuously within each group; do not reuse a number after a revision.

8. Acceptance criteria

This script passes only when all of the following are true:

• Every allowed privilege in the role-privilege matrix works for the role that should have it, and every denied privilege is blocked for the roles that should not, each with recorded actual results and evidence.
• The configured password complexity, history, age, and lockout values behave exactly as set in section 5.
• No single account can both perform and approve the same action; any combined-duty case is a documented, justified exception with a compensating control.
• Disabled and expired accounts cannot authenticate, session timeout enforces re-authentication, and direct (non-menu) requests for restricted functions are refused server-side and logged.
• No step is left blank or ambiguous; every deviation raised during execution is resolved with a documented disposition, and any retest is recorded under its own step or attachment.

A single denied privilege that the system actually allows is a failure of the script, investigated as a critical deviation, not averaged away against the passing steps.

9. Evidence index

10. Deviations raised during execution

Any step that does not meet its expected result, any departure from the written steps, and any prerequisite not met is recorded here and managed per the parent protocol and <<FILL: deviation / test-incident SOP-ID>>. Cross-reference the deviation number on the failing step.

A blocked-action test that instead succeeded is, by default, critical: it means the configured control does not hold. Do not downgrade it without a documented impact assessment and QA agreement.

11. Execution summary

12. Test account cleanup

Security testing creates accounts, locked states, and aged passwords that must not leak into the controlled environment. Record the disposition of every test artifact.

13. Sign-off

The tester executes and signs; an independent reviewer who did not execute the test confirms the record is complete, the evidence supports each pass (especially the denial evidence), and deviations are resolved. The reviewer should not be the same person who executed the script.

14. References

21 CFR Part 11 (electronic records and signatures), in particular 11.10(d) limiting system access to authorized individuals, 11.10(g) authority checks, and 11.300 controls for identification codes and passwords. 21 CFR 211.68 (automatic, mechanical, and electronic equipment), for limiting access and input/output checks. EU GMP Annex 11 (Computerised Systems), section 12 on security and access control. EU GMP Annex 15 (Qualification and Validation), 2015 revision, for qualification testing principles. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final), for scaling test rigor to risk. GAMP 5, Second Edition (a risk-based approach to compliant GxP computerized systems). ICH Q9 (Quality Risk Management), for the risk basis of access control depth. For medical device software: 21 CFR Part 820 (QMSR, effective 2 February 2026, incorporating ISO 13485:2016) and IEC 62304.

Confirm the current version and clause numbers of each reference before issue.

15. Revision history

Filled specimen

The following shows the script executed for an example laboratory information management system, verifying role-based least privilege, lockout, segregation of duties, and disabled-account behavior. The company, system, accounts, and numbers are illustrative; replace them with your own.

Header (extract)

Configured policy values under test (extract)

Test steps (executed, extract)

Execution summary

Sign-off

In this example the tester recorded the exact denial message text for every blocked action, not “access denied as expected”, confirmed server-side enforcement of the URL bypass rather than a hidden menu, and showed that the record creator could not approve the same record. Twelve of the twenty steps were negative tests, which is where the security assurance actually sits. Had step 7.3.2 instead let analyst1 approve a record they created, the tester would have marked it Fail, raised a critical test incident, and held the conclusion, which is exactly what section 10 is built to capture.

Common inspection findings this template prevents

• Access control “tested” only on the happy path, with no negative steps proving that a forbidden action is actually blocked.
• A denial recorded as “access denied as expected” with no message text and no proof the action did not take effect.
• A restricted function merely hidden from the menu but still reachable by direct URL or parameter, never tested for server-side enforcement.
• Password and lockout policy declared in the specification but never exercised, so the live setting could differ from the documented value with no evidence either way.
• The same account able to create and approve, or an administrator able to grant themselves data privileges, with no segregation-of-duties test and no documented exception.
• Disabled or terminated accounts that still authenticate, because the test never attempted a disabled-account login.
• A combined-duty exception used in practice with no written justification and no compensating control such as independent review of administrator actions.
• The security or audit log never checked to confirm that failed logins, lockouts, and bypass attempts are recorded.
• The same person executing and reviewing the security script, with no independent check that the denial evidence supports each pass.

How to adapt this template

1. Set your test script ID, parent protocol, system version, authentication model, and effective date in the header, and confirm you are testing in a qualified non-production environment.
2. Paste your actual role-privilege matrix into section 3 and write one set of steps per role, covering both the privileges it should have and the privileges it must not.
3. Set the real configured policy values in section 5 from your configuration specification, then make sure section 7.2 challenges each one by behavior.
4. Add roles and denied-privilege rows as your access model requires; the four groups in section 7 are the minimum, not the ceiling. For SSO or federated systems, add steps for centrally disabled accounts and token expiry.
5. Decide before execution how any unavoidable combined-duty case is handled, and record it as a justified exception with a compensating control rather than letting a step quietly pass.
6. Point the cross-references in sections 4, 10, and 13 to your real protocol, deviation or test-incident procedure, and review and approval process, and make sure section 12 cleanup leaves no test account or locked state behind.
7. Confirm every regulation in section 14 against the current published version before issue.