Security Requirements and Acceptance Testing Under ISO 27001

Direct answer: ISO 27001 security requirements should be defined early enough to influence acquisition or development and written so they can be verified. Acceptance testing should then demonstrate, with traceable evidence, that the implemented system meets those requirements and that unresolved results receive an explicit risk decision.

ISO/IEC 27001:2022 Annex A control 8.26 addresses application security requirements, while A.8.29 addresses security testing in development and acceptance. Other controls may apply to architecture, outsourced development, test information, change and operational readiness.

This article provides AuditPrepared guidance. It does not reproduce standard text. Testing depth should follow risk, system criticality, data, legal obligations and the organisation’s Statement of Applicability.

Start with sources, not a generic security list

Security requirements should reflect the system’s actual context. Gather inputs from:

• information classification and data flows;
• business processes and misuse scenarios;
• risk assessments and threat analysis;
• laws, contracts and customer commitments;
• architecture and secure engineering principles;
• identity, logging, recovery and retention standards;
• supplier service and shared-responsibility boundaries;
• previous incidents, defects and audit findings; and
• operational support and monitoring needs.

The requirement owner should be able to explain why each material requirement exists. This prevents teams from copying controls that do not fit the service while missing risks that do.

Write requirements that can be tested

“The application must be secure” cannot be objectively accepted. A usable requirement identifies a subject, expected behaviour, conditions and a measurable result.

Weak statement	Testable direction
Use strong authentication	Administrative access uses the approved identity service and defined authentication strength
Log important activity	Specified security events contain user, action, target, time and outcome and reach monitoring within the agreed interval
Protect sensitive data	Defined information classes use approved protection during transfer and storage
Restrict access	Named roles can perform authorized actions; other roles receive a controlled denial
Recover quickly	The service and required security functions meet approved recovery objectives in a test

Detailed values should come from controlled organisational standards. Avoid publishing secrets or sensitive defensive thresholds in broadly accessible documents.

Assign ownership and priority

Every requirement needs an accountable owner and priority. Owners may include information, service, risk, privacy, legal and security roles. Priority helps teams resolve conflicts and prevents a critical control from being traded away without authorization.

Record whether a requirement is mandatory because of law or contract, required by risk treatment, or recommended for defence in depth. If a requirement changes, retain the reason, approver and impact assessment.

Use the secure engineering principles guide to connect individual requirements to consistent architecture decisions.

Maintain end-to-end traceability

A simple traceability record can link:

1. source obligation or risk;
2. security requirement;
3. architecture or design decision;
4. implementation component;
5. test case and expected result;
6. actual result and evidence; and
7. defect, exception or acceptance decision.

Traceability reveals gaps in both directions. A requirement without a test may not be verified. A security feature without a requirement may have no owner, rationale or acceptance criterion.

Keep the record usable. For a small low-risk system, a concise table may be enough. A critical platform may need controlled lifecycle tooling and automated evidence.

Design a risk-based test strategy

Testing should use complementary methods rather than rely on one scan. Depending on risk, include:

• review of requirements and architecture;
• code and dependency analysis;
• configuration and infrastructure tests;
• unit, integration and end-to-end security tests;
• authorization and negative tests;
• vulnerability assessment and penetration testing;
• recovery, resilience and failover tests;
• logging and alert verification; and
• supplier evidence or independent assurance.

The NIST SP 800-115 technical guide provides authoritative guidance for planning and conducting technical security assessments. The organisation still needs to select methods proportionate to its ISO 27001 risks.

Test failure as well as success

Security behaviour often appears when an action is denied or a component fails. Test:

• unauthorized roles and expired sessions;
• malformed and unexpected input;
• missing dependencies or unavailable identity services;
• exhausted limits and degraded capacity;
• interrupted transactions and rollback;
• disabled logging or delayed monitoring;
• attempted bypass of workflow approvals; and
• recovery from protected backups.

Define the expected secure state. A denied request should not disclose sensitive details, corrupt data or leave a privileged operation partly complete.

Protect test environments and information

Realistic testing improves assurance, but production data and credentials can create new risk. Apply Annex A control 8.33 considerations for test information as relevant:

• use synthetic or minimized data where practical;
• authorize any production-data use;
• mask sensitive fields appropriately;
• restrict tester and supplier access;
• isolate the environment;
• manage test accounts and secrets;
• log activity; and
• remove data and access after testing.

Similarity to production should focus on the conditions needed for valid results, not uncontrolled copying of sensitive information.

Define acceptance before the test

Acceptance criteria should state:

• which requirements must pass;
• permitted defect severity and quantity;
• evidence needed;
• who can accept residual risk;
• required retesting after correction;
• operational readiness conditions; and
• conditions that block release.

If criteria are invented after results arrive, delivery pressure can distort the decision. Set them during planning and change them only through controlled approval.

Preserve tester independence where risk warrants it

Developers should test their work, but independent review can reduce confirmation bias for high-impact systems. Independence may come from another team, a qualified internal assessor or an external provider.

Independence does not remove system-owner accountability. The owner must confirm scope, provide accurate context, evaluate results and decide whether residual risk is acceptable.

Handle findings through closure

Classify results using defined criteria that consider exploitability, exposure, business impact and existing safeguards. For every material finding:

• assign an owner and due date;
• record the affected requirement and component;
• correct or formally treat the risk;
• retest the specific failure and relevant regression paths; and
• preserve evidence of closure.

A long report is not proof of control if critical findings remain unowned. Connect remediation changes to the ISO 27001 change-management process.

Preserve design and operating evidence

Design evidence

• requirements method and sources;
• role and approval model;
• traceability approach;
• test strategy and independence criteria;
• acceptance and release rules;
• test-information safeguards; and
• exception and risk-acceptance process.

Operating evidence

• approved system requirements;
• architecture and threat-review records;
• test plans, cases and results;
• automated pipeline outputs where relevant;
• defects, remediation and retest records;
• acceptance decision and residual risk;
• test accounts and data disposal evidence; and
• post-release validation.

Trace a worked example

A company acquires a customer-support platform that will store confidential case records. Requirements cover role-based access, regional storage, event logging, retention, export approval and service recovery.

The supplier demonstrates configuration and assurance evidence. The organisation then tests its own tenant: ordinary agents cannot export all cases, supervisors can export only after approval, each export produces the required event and expired guest access is denied. A recovery exercise confirms that restored service retains access rules and logs.

One alert arrives too slowly for the approved monitoring requirement. The service owner delays acceptance of the integration, corrects the routing and records a successful retest. The final decision is traceable from client information risk to operating evidence.

Audit through requirements and releases

Choose systems with different acquisition and development models. Include a new service, a major change and a supplier-managed application. For each sample:

1. trace selected risks to requirements;
2. assess whether requirements are measurable;
3. inspect design and implementation linkage;
4. compare test conditions with production-relevant risk;
5. verify expected and actual results;
6. trace failures to correction or accepted risk;
7. inspect release authorization; and
8. confirm post-release controls operate.

The Annex A control lookup helps teams navigate connected controls without replacing the licensed standards.

Result	Example
Pass	Material risks produce testable requirements, traceable results and authorized acceptance decisions.
Partial	Security tests occur, but requirements, acceptance criteria or retesting evidence are incomplete.
Fail	Release depends on informal assurance, failed requirements are ignored or test evidence cannot be linked to the deployed system.

Common questions

Must every requirement have its own test case?

Every material requirement needs verification, but one test may cover several requirements and some requirements are verified by review or inspection. Preserve clear traceability.

Is penetration testing sufficient for acceptance?

Usually not. It samples exploitable behaviour at a point in time. It does not by itself verify every access, logging, recovery, privacy or supplier requirement.

Can supplier assurance replace customer testing?

It can reduce duplicated work where scope and evidence are suitable. The customer still needs assurance over its configuration, integrations, users and responsibilities.

Make acceptance an evidence-based decision

Security improves when requirements and tests are parts of one chain. Define what must be protected, state observable outcomes, test under realistic conditions and require explicit decisions for unresolved results. That makes system acceptance defensible to owners, customers and auditors.