All resources
// Resources

Security Testing Evidence for ISO/IEC 27001:2022

Published August 11, 2026

What source says, what evidence can show

ISO identifies ISO/IEC 27001:2022 as edition 3, published October 2022; its page describes requirements for an information security management system. The page also distinguishes implementation from certification: certification is performed by a certification body, with accreditation relevant to that body’s competence. This article does not reproduce the standard, interpret every requirement, or decide conformity.

Security testing is implementation evidence. It may support risk treatment, corrective action, monitoring, or management review when the organization’s ISMS defines that use. It cannot by itself prove an ISMS conforms, earns a certificate, or guarantee that controls work in all circumstances. Operator, legal, and appropriate accreditation/certification reviewers must decide scope, contractual wording, and assurance conclusions.

NIST SP 800-115 was published in September 2008. It provides technical-test planning and assessment guidance. It is a method reference, not ISO/IEC 27001 requirement text.

Evidence also needs a decision date. A finding may remain technically accurate after release, while its risk treatment or management priority changes. Record the decision maker, review cadence, and trigger for reassessment when service scope, supplier dependency, or material architecture changes.

Evidence-to-decision record

RecordNeeded fieldsPass criterionOwner
Risk linkasset, threat, risk ID, treatment decisionapproved risk record points to test objectiverisk owner
Test chartertargets, versions, methods, ROE, exclusionsauthorization signed before testingsystem owner
Observationtimestamp, tester, method, result, evidence hashanother reviewer can identify exact basisassessment lead
Findingcondition, impact rationale, severity, limitationno unsupported control conclusionfinding owner
Corrective actionchange ID, owner, target date, exceptionaccountable decision is recordedengineering owner
Effectiveness checkfixed version, repeat method, result, residual riskretest supports closure or formal acceptanceassessment lead

Completed example: IAM service 5.4.0 is linked to risk R-019 about privileged access. Signed scope permits authenticated authorization testing and prohibits account lockout testing. Evidence contains test account approval, timestamps, sanitized responses, report hash, and finding IAM-07. Engineering deploys 5.4.1; retest confirms a standard administrator cannot export audit configuration. The pass is traceability from risk to retest. It is not “ISO certified.”

Test quality, exceptions, and remediation

A useful test has a defined question. “Test the application” fails because target, control purpose, and success rule are absent. State whether test validates identity separation, secure change outcome, logging visibility, or another approved objective. Keep tool version, environment, data handling, and limits. Do not retain secrets or raw personal data unless authorized and protected.

Mark evidence failed when authorization is missing, target version cannot be established, finding severity has no rationale, evidence is altered without a preserved original, or remediation is closed solely by a ticket state. Remediation should record owner, planned change, dependency, due date, validation method, and delay decision. An exception needs business reason, risk, compensating control, approving authority, review date, and expiry. Expired exception is open work.

Evidence freshness

Set a freshness rule before review. A result tied to retired release, changed authentication flow, new supplier integration, or altered data classification may no longer answer original test question. Record last-valid date and reassessment trigger beside each control objective. This keeps management from treating archived test result as live assurance.

Management review handover

Package testing material as an indexed decision record: risk reference; approved charter; evidence manifest; limitations; finding register; exception decisions; corrective-action status; retest result; and retention owner. Management can then distinguish evidence of a completed test from evidence that a risk treatment remains open.

Use supported, partly supported, and not supported for each stated test objective. Do not convert those labels into control conformity. A reviewer may need broader ISMS records, interviews, and independent audit work before reaching any assurance conclusion.

Worked evidence challenge

For IAM-07, reviewer verifies scope authorization covers 5.4.1, compares original and retest roles, opens immutable evidence manifest, and checks residual-risk owner decision. If test shows administrator denial but audit export function was removed rather than access checked, record design change and request service-owner confirmation of intended function before closure. Output is supported for stated test objective, partly supported, or not supported; it never becomes an ISO conformity result.

Assurance boundary

Before using a report in an ISO program, confirm current edition/amendment status with ISO, check the organization’s own ISMS procedures, and obtain operator/legal review. Any certification statement needs review by relevant accredited-conformity channels. This workflow improves evidence quality only; it makes no compliance, certification, audit-pass, or security-outcome guarantee.

Sources

Worked closure check

For production access-control evidence, retain risk ID, approved charter, service release, role matrix, test timestamp, assessment lead, and residual-risk decision. Result may support only named ISMS test objective; it cannot establish ISO/IEC 27001 conformity, certification, or legal assurance. Authentication redesign or supplier dependency change triggers targeted reassessment. Independent reviewer picks one role-denial result, compares original and retest artifacts, and confirms disposition against risk register. Unexamined control areas and delayed actions remain separately identified.

Have a system that needs testing?