ISO 27001 Compliance Audit: How to Prove Your Controls Actually Work

Here is a scene that is easy to picture in a mid-sized company. A B2B payroll service is preparing for an external audit because a large customer has made an ISO/IEC 27001 certificate a condition of renewing the contract. The policies are written, the risk register is filled in, and the Statement of Applicability neatly records that the web application "is regularly tested for vulnerabilities." In the meeting, the auditor asks to see how that happens. The team brings a forty-page scanner report from a year ago: no description of scope, no retest date, no link to risks. Half the findings are marked "high," and nobody is quite sure which of them were fixed.

This is a fictional example, but the gap in it is easy to recognise: the documents describe a system that is supposed to work, and the evidence that it does work is missing. An ISO 27001 compliance audit is, above all, work with evidence. One key question is: "how do you know this control is actually effective?"

Below we look at which reviews hide behind the words "ISO 27001 audit," where penetration testing fits into them, how to assemble technical evidence, and how to choose a provider without buying promises nobody is entitled to make.

What an ISO 27001 compliance audit actually examines

ISO/IEC 27001 sets requirements for an information security management system (ISMS). The current edition is ISO/IEC 27001:2022, the third edition, published in October 2022; Amendment 1 to it was published in 2024. If your documentation, a customer contract or an auditor's request refers to a specific edition, that matters: wording and control sets differ between versions, and you should cite the one your system is actually built on.

The standard can be implemented without certification — ISO states plainly that certification is an optional, separate process. ISO itself certifies nobody: certificates are issued by an external certification body, and the accreditation of that body is yet another, separate concept. So "we were audited by ISO" is wrong, while "who accredits your certification body?" is an entirely fair question.

This article concentrates on the technical and evidential side: how to verify that declared security controls are effective, and how the results feed risk treatment and management review. We deliberately do not interpret the standard clause by clause. The list of mandatory documents, the stages of a certification audit and the parameters of the certification cycle should be checked against the current text of ISO/IEC 27001 and with your chosen certification body.

Internal audit, readiness assessment and certification: different jobs under one name

The label "ISO 27001 audit" covers different kinds of work with different initiators and outcomes. Confusing them leads a company to order one thing and expect a result that only another can deliver.

Why a pentest is not a certification audit

A penetration test answers a narrow, concrete question: what can an attacker do with these systems, on these dates, using these methods. A certification audit answers a different question: does the management system work within the declared scope — are risks identified, is the choice of controls justified, does management review the results, are nonconformities corrected.

A pentest can be strong evidence for individual controls and an important input to risk treatment. A test report, readiness assessment and internal audit are not certification or the certification body's decision. An internal audit may reach an internal, scope-bounded conformity conclusion and record nonconformities, but it does not issue an independent certificate. A provider that sells a pentest as an "ISO 27001 compliance audit with a guaranteed certificate" is mixing up concepts, and that is a reason to be wary.

Three layers of evidence: process, control rationale, effectiveness

Most ISMS evidence is documentary: policies, risk assessments, risk-acceptance decisions, review minutes. But the auditor also asks how the organisation knows its technical controls work as written. It helps to split evidence into three layers.

The first layer is management-system evidence: the process is defined, roles are assigned, records are kept, results are reviewed.

The second layer is control-design evidence. Every selected control has a rationale linking it to a specific risk from the assessment. If the risk register contains the threat of administrator accounts being compromised and the control list contains multi-factor authentication for administrative access, the link between them should be explicit rather than implied.

The third layer is effectiveness evidence: results of tests, scans, configuration reviews and monitoring, with dates and scope. This is where the gaps that documents conceal show up. Suppose the policy requires multi-factor authentication for human administrator accounts, but an undocumented service-account API key grants equally broad access without justified scoping, rotation or monitoring. That is a separate access path that may defeat the control objective. Service and break-glass identities need their own explicitly designed controls; absence of an interactive second factor is not, by itself, proof of a defect.

Technical testing works mainly on the third layer, and a single result serves two purposes at once: it is an input to risk treatment and an audit record that the control was checked.

Planning technical checks: NIST SP 800-115 without illusions

For a testing procedure your ISMS can reference, NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, remains a useful framework. It was published in September 2008 and superseded SP 800-42. The document helps organisations plan and conduct technical tests and examinations, analyse findings and develop mitigation strategies.

For ISO 27001 purposes one idea in it matters most: technical testing and examination serve two goals — finding vulnerabilities in a system or network, and verifying compliance with a policy or other requirements. For an ISMS, a test is not only bug hunting; it is a way to confirm that what the policy declares is actually happening.

The guide describes a formal assessment in three phases: planning, execution and post-execution. Planning defines objectives, scope, rules of engagement and constraints. Execution applies the chosen techniques. Post-execution analyses findings and develops mitigation recommendations. The "fix, retest, close" cycle discussed below is our own practical extension for the ISMS, not NIST's literal structure.

The guide does not claim to be a complete testing programme; it offers an overview of key elements and of specific technical techniques with their strengths and limitations. That is a useful discipline for audits: noting what a technique cannot show tells the auditor the organisation understands the limits of its evidence. An external perimeter scan says nothing about authorisation inside the application. A configuration review does not show how the system behaves under real attack.

Mind the document's age: a 2008 publication does not cover cloud, API-centric architectures or AI-based systems. Use it as a process skeleton and supplement it with current guidance.

1. Risk and scopeThe ISMS risk assessment decides which systems and controls to check and what is deliberately excluded from scope
2. Choice of methodEach control gets the lightest method that still yields convincing evidence, from configuration review to pentest
3. Authorised testingWork runs under the system owner's written authorisation with fixed scope, time window and stop rules
4. Remediation and retestFindings are tied to root causes, fixed and retested, with dates and named owners
5. Register and decisionsThe result goes into the evidence register, risk treatment and management review

Applications and APIs in ISMS scope: ASVS, WSTG and the role of the OWASP Top 10

If web applications or APIs fall within the ISMS scope, OWASP offers three resources that solve different problems. Mixing them up means handing the auditor the wrong type of evidence.

The OWASP Application Security Verification Standard (ASVS) provides a basis for testing the technical security controls of web applications and also gives developers a list of requirements for secure development. Its aim is to normalise the range of coverage and rigour in application security verification on the market through an open, commercially workable standard. The source material examined version 5.0.0; before work starts, check which version is current at the time of testing and name it explicitly in the contract.

The OWASP Web Security Testing Guide (WSTG) is a guide to testing the security of web applications. Here WSTG 4.2 is used as a pinned example; the contract and report should name the version actually chosen for the assessment. The division of roles is simple: WSTG describes how to test, and ASVS describes which requirements those tests confirm. We have written in more detail about building such a review from scope to decisions in our piece on a standards-based application security audit.

Versioned requirements as an audit trail

ASVS has a mechanism ISMS teams should use. Requirements carry versioned identifiers such as v5.0.0-1.2.5, and the project recommends always stating the version because numbering can change between releases. Requirement lists are available in machine-readable formats, including CSV and JSON.

The practical point is this: if a test report shows a versioned requirement identifier and a WSTG test-case reference next to each check, an auditor a year later can see which requirement was checked, against which version and when.

A hypothetical example. The ISMS states that user sessions are protected against hijacking and fixation. A record saying "ASVS session-management requirements, version 5.0.0, checked with these WSTG test cases on this date; two requirements not met, findings fixed and confirmed by retest on that date" is evidence that can be verified. Note that ordinary HTTP is perfectly able to support server-side session state; the question is not the protocol but how the session identifier is issued, bound, expired and revoked.

The Top 10 is for awareness, not for test scope

The OWASP Top 10, 2025 edition, is an awareness document reflecting broad consensus about the most critical web application security risks. It is good for training and for discussing risk with management, but it is not a verification standard. If a report boils down to "tested against the OWASP Top 10," the auditor is entitled to ask which requirements were checked and what confirms it — and the answer comes from ASVS or an equivalent detailed methodology.

Prioritising findings: root causes and exploitation data

An audit trail is more convincing when the order of fixes follows reproducible logic rather than a scanner's severity label or an engineer's intuition. The MITRE CWE weakness classification helps here.

The 2025 CWE Top 25 Most Dangerous Software Weaknesses is based on root-cause analysis of CVE records in the dataset for the 2025 edition. According to MITRE, they are often easy to find and exploit, with consequences up to system takeover, data theft or application disruption. Two more useful lists are published alongside it: the CWE Top 10 KEV Weaknesses, which ranks weaknesses using the CISA Known Exploited Vulnerabilities catalog — that is, vulnerabilities with confirmed exploitation — and the On the Cusp list of weaknesses that narrowly missed the main ranking.

For an ISMS the value lies in the connection. When an applicable technical finding is mapped to a CWE identifier, the organisation can show that its priorities take account of root causes and real exploitation data, not just tool scores; process and governance findings may have no suitable CWE. Several findings of the same class, such as missing object-level authorisation checks, may indicate a shared systemic flaw, but may also have independent causes. That is a signal to investigate the architectural root cause, fix it where confirmed, and then check every affected path. How to build this logic without relying blindly on a single score is covered in our article on risk-based vulnerability prioritisation.

Suppliers as part of the evidence: Secure by Design and Secure by Demand

A large share of security controls depends on software and cloud suppliers, and the auditor expects not only contracts but signs that the organisation understands what it is buying.

The CISA Secure by Design programme promotes the idea that products should be secure by default and that baseline security features — multi-factor authentication, logging, single sign-on — should be provided at no extra charge. Software manufacturers can publicly sign the Secure by Design Pledge and commit to good-faith efforts on seven goals; some signatories publish progress reports.

For the audit this becomes a concrete check: ask the supplier whether it has signed the pledge, review its progress report if there is one, and record the answer in the supplier file. The CISA Secure by Demand guide is written precisely for customers and contains questions you can ask during procurement. Signing the pledge does not replace your own assessment and does not prove the absence of vulnerabilities, but it gives you a verifiable point of discussion. We describe a broader approach to assessing vendors, SaaS and software suppliers in our piece on third-party risk security assessment.

Observable controls and links to other frameworks

Many organisations live in several frameworks at once. NIST Cybersecurity Framework 2.0 helps organisations understand and manage cybersecurity risk; its resource centre offers profiles, quick-start guides and informative references — mappings that show where different resources overlap.

CSF profiles are handy for describing current and target states in language management understands, but the ISMS remains the governing system: mappings save duplicate work, they do not replace ISO/IEC 27001 requirements.

Controls you can see from outside

At the most concrete level, some web controls can be observed directly. MDN's HTTP documentation describes mechanisms whose configuration is visible in a server response: Content Security Policy, which helps detect and mitigate certain attacks including cross-site scripting and data injection; CORS and Cross-Origin Resource Policy; Permissions Policy; cookie attributes such as Secure, HttpOnly and SameSite; and HTTP authentication mechanisms. MDN also points to tools such as HTTP Observatory for checking a site's configuration.

A dated snapshot of these headers is cheap, reproducible evidence that a documented web-hardening control is actually applied in production. But do not overrate it. A CSP header being present does not prove the policy is strict enough, and a tidy CORS setup on one domain says nothing about the neighbouring API. A snapshot is evidence of configuration, not of resilience to attack. Moreover, a snapshot from a test or pre-production environment cannot be carried over to production without checking: load balancer, CDN and reverse-proxy configurations often differ there.

Trade-offs: depth, independence, frequency and versions

Document review is cheaper but shows control design, not effectiveness. Testing shows effectiveness, but only for the systems, dates and techniques in scope. Every method has blind spots, and an honest register records them.

An internal team knows the environment and can check it continuously; an appropriately selected external provider can add an independent view and comparable method when qualifications, conflicts, scope and approach are checked. A sensible arrangement, in our view, combines ongoing internal checks with independent assessment of the riskiest part of the scope at a risk-derived frequency — a practical recommendation, not a requirement of the standard.

Frequency is where myths are especially common. ISO/IEC 27001 does not set a universal pentest interval, and a provider citing "the standard's requirement to test once a year" is passing off its own rule as someone else's. Frequency should be derived from the risk assessment, from how the organisation itself designed the control, from contractual obligations and from any separately applicable rules. Significant changes — a new external service, a move to another cloud, rewritten authorisation — often give a stronger reason to test than the calendar does.

A new version of a standard, such as ASVS 5.0.0 or the OWASP Top 10 2025, makes testing more current but may change identifiers and break comparability with earlier reports. Record the version for every check, and when you migrate, map old identifiers to new ones.

Finally, breadth and depth of scope compete for the same budget. Choose between broad review and deep testing according to the risk assessment and the evidence needed; the riskiest parts of scope generally require sufficient depth and precise documentation.

The evidence register and preparing tests safely

Technical testing must have documented authorization from every party whose authority is needed for the systems and environments in scope; that may be an operator, asset owner, tenant or delegated control owner. The authorization records scope, time window, contacts, constraints and stop rules. For production systems within ISMS scope, prefer non-destructive methods and an agreed course of action in case something goes wrong.

The practical output of preparation should be an evidence register. For every control declared effective, it records the check or review performed, the methodology and its version, the date, the scope, the result, applicable CWE mapping for technical findings or an explanation of non-applicability, owners and remediation dates, and the retest outcome. The results then flow into risk treatment and management review — otherwise testing does not influence decisions.

A ticket closed in the tracker does not prove a fix works: you need to repeat the original scenario, check neighbouring paths to the same function and make sure the fix reached the environment that is in scope. More on this in our piece on penetration test remediation validation.

If you are preparing an ISMS for audit and want to work out which systems and controls deserve technical testing and which can be confirmed through configuration or document review, that is a good topic for a conversation with our team. On the pentest scope page you can set out the systems, boundaries and expected report artefacts: versioned requirement references, CWE mapping where applicable, and retest. How testing that prepares for an audit differs from an ordinary pentest is covered in detail in our piece on penetration testing for audit readiness.

How to choose an ISO 27001 audit or readiness service

Open methodologies do not rank or certify providers — not auditors, not readiness consultants, not testing firms. So the choice should rest on a verifiable methodology and concrete deliverables.

Ask which published methodologies the provider follows and how it documents the limitations of its techniques. Ask for an anonymised sample report: does it include ASVS requirement versions, scope and exclusions, reproducible steps? Ask whether applicable technical findings are mapped to CWE and whether prioritisation uses exploitation data, such as the KEV-based list. Make sure the contract includes written authorisation for testing, rules of engagement and constraints for safely testing production systems.

Check separation of roles separately. The party that helped build the controls should not be the only one assessing their effectiveness — otherwise the independence of the evidence is in question. Verify claims of accreditation or qualification directly with the issuing organisation, not from marketing material. If the provider also sells software or a platform, use the questions from the CISA Secure by Demand guide.

And the main filter: avoid offers that promise a certification outcome. The decision belongs to the certification body, and nobody can guarantee it.

Pentest.red performs penetration testing and technical assessments whose results can serve as evidence of the effectiveness of individual ISMS controls. Certification audits, conformity opinions and legal assessment require a certification body or a separately qualified consultant. If what you need is the technical part, start with our penetration testing service and discuss which artefacts your auditor expects.

A decision for your profile, and the bottom line

The decision process fits into five steps that each leave a written trail. Define the ISMS scope and the risks it must treat. List the controls whose effectiveness needs to be confirmed. For each control, choose the lightest method that yields convincing evidence: document review, configuration snapshot, automated scanning or structured testing based on NIST SP 800-115 and the OWASP guides. Decide who performs each piece of work based on risk and independence requirements. Record the results in the evidence register and feed them into risk treatment.

If the ISMS scope covers mainly business processes and includes little in-house software, prioritise documentary evidence, configuration snapshots and supplier oversight. If customer-facing web applications and APIs are in scope, add ASVS verification and WSTG testing with versioned references. If the organisation develops software itself, add CWE root-cause tracking for applicable technical classes and Secure by Design expectations for its own products and for component suppliers.

Ultimately, an ISO 27001 compliance audit tests whether an organisation can prove what it claims. Open, versioned and maintained methodologies for technical checks do not replace the standard or the certification body's decision. But they make ISMS claims verifiable, the audit more predictable and the choice of provider more deliberate.