Pass your ISO 27001 certification
Pentest Today produces the technical evidence and documentation an ISO 27001 auditor looks for — pentest results, scan output, and policies pre-mapped to Annex A controls.
What a ISO 27001 review asks for
ISO/IEC 27001 certifies that you run an Information Security Management System (ISMS) with the Annex A controls in place.
What closes each requirement
| Control | What they ask | Evidence | Where it comes from |
|---|---|---|---|
| A.8.8 · technical vulnerability management | Evidence that technical vulnerabilities are found in a timely way, evaluated, and actually closed — not that a scan ran once before the audit. | The penetration test report — severity on every finding, a CVSS v3.1 vector and base score where the finding is scored, the affected asset, and, on the findings that have them, evidence, reproduction steps, and remediation — plus the retest restating each one as fixed or not fixed. | The pentest workflow's client-ready PDF, and the Vulnerability Management Policy's scanning cadence and per-severity remediation SLA, both generated from the same intake. |
| A.8.9 · configuration management | That configurations for your systems and network devices are established, documented, and checked against a baseline — not left to whatever got deployed and never revisited. | Configuration findings inside the pentest report itself: a missing HSTS header, an absent Content-Security-Policy, no clickjacking protection, a sensitive path like /admin answering 200 instead of being blocked — each carrying the same severity, evidence, and remediation fields as any other finding, so a drifted setting gets a date and an owner. | The scan engine's header checks behind the paid report — the same header signals the free passive check runs before an account exists — plus the common-path probing that only runs once testing is authorized. |
| A.8.28 · secure coding | That a secure-coding standard is actually enforced in review and testing, not written down as a policy nobody checks work against. | The Secure SDLC Policy's secure-coding section — OWASP Top 10 practices, mandatory peer review, secrets kept out of source control — read against the OWASP Category the pentest report attaches when a finding maps to one, so a recurring category is a signal the standard isn't holding rather than a line item. | The policy pack's Secure SDLC Policy, generated from the intake's code review and deployment process, plus the report's OWASP mapping where a finding carries one. |
| A.5.15 · access control | Who can reach production and customer data, on what basis they were granted it, and whether that still matches who's actually on the team. | The Access Control Policy — unique, individually attributable accounts, MFA required on production and administrative access, and access to production and sensitive data reviewed at least quarterly — checked against your identity provider's current member list rather than the policy's own say-so. | The policy pack, generated from the intake's authentication method and MFA status, so the policy states what's configured rather than a template default. |
| A.5.19 · supplier relationships | That vendors and subprocessors were assessed before they touched anything, sorted by how much risk they actually carry, and checked again on a cadence — not vetted once at signup and never again. | The Vendor Management Policy's tiering table — high, medium, and low risk, each with its own diligence step — and an annual re-review commitment for the high tier, which is the level of granularity a surveillance auditor samples against. | The policy pack's Vendor Management Policy, generated from the intake's vendor list and tiered by the data each one touches. |
| A.5.24–5.26 · incident management | A plan for how a suspected incident gets assessed, decided as an incident or not, and responded to, with roles defined ahead of time rather than an ad hoc scramble the one time it happens. | The Incident Response Policy's severity tiers and response-time targets, its containment-through-recovery lifecycle, and the named incident response owner who runs it, plus a post-incident review completed within five business days for the top two severities. | The policy pack's Incident Response Policy, generated from the intake's named incident owner and monitoring tooling. |
What the report actually contains
Illustrative example, written in the format the product generates. Not taken from a customer engagement.
How this review actually runs
Certification runs through an accredited certification body, not through Pentest Today, and it moves in a fixed order: Stage 1, Stage 2, then three years of surveillance.
Stage 1 is a documentation review. The auditor reads the ISMS scope, the risk assessment methodology, and the Statement of Applicability, and checks that each applicable control has a policy or a process behind it on paper. Nothing technical is sampled yet — a gap found here is cheap, because it's a missing document rather than a missing control.
Stage 2 is where the paper gets tested. The auditor samples applicable controls and asks for the artifact behind each SoA row: for 8.8, that means the penetration test report and the vulnerability management process feeding it. This is also where certification stalls most often — an SoA row marking 8.8 'applicable, implemented' and citing 'annual penetration testing,' with nothing dated actually attached. The auditor doesn't take the row's word for it; it asks what's behind it.
Once certified, the certificate runs three years, with a surveillance audit in each of the first two and recertification at the third. Surveillance samples a subset of controls, not all of them, but a system added since the last visit and never retested is exactly the kind of gap a surveillance auditor is trained to look for — the SoA row that was solid at Stage 2 and has since gone stale.
What gets this sent back
Scan
Authenticated and external scans across web, API, and cloud surface the issues before an assessor does — de-duped, triaged, and mapped to CVE/CVSS.
Pentest
Approved-target scans become a client-ready pentest report: validated findings, evidence, reproduction steps, remediation, and the retest letter auditors accept.
Policy Generator
Generate the policies and system architecture diagrams the review expects — access control, cryptography, incident response — pre-mapped to controls.
Start your Pentest
Our agent swarm and human experts test your endpoints and deliver an audit, fast.
HIPAA
The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic protected health information (ePHI).
GDPR
GDPR Article 32 requires appropriate technical and organizational measures to secure personal data, including regular testing of their effectiveness.
PCI DSS
PCI DSS protects cardholder data and explicitly requires both internal and external penetration testing at least annually.
NIST CSF
The NIST Cybersecurity Framework organizes security around Identify, Protect, Detect, Respond, and Recover.
FedRAMP
FedRAMP authorizes cloud services for U.S. federal use, built on NIST 800-53 controls and requiring penetration testing.
CMMC
CMMC verifies that defense contractors protect Controlled Unclassified Information (CUI) per NIST 800-171.
ISO 27001, answered
Is a penetration test required for ISO 27001?
Annex A doesn't name 'penetration test' as a mandatory line item, but 8.8 requires managing technical vulnerabilities, and auditors routinely expect a test as the evidence behind it. What satisfies Stage 2 is a dated report with per-finding severity and a retest, not a scan export with no reproduction steps.
How does the evidence map back to my Statement of Applicability?
Each row cites the Annex A control number your SoA already lists, names the artifact that closes it, and says which generator produces that artifact — so instead of writing 'penetration testing' in a cell, your SoA row points at a dated report an auditor can actually open.
What's the difference between Stage 1 and Stage 2?
Stage 1 reviews your documentation — the ISMS scope, risk methodology, and Statement of Applicability — and checks that each applicable control has something written behind it. Stage 2 tests whether those controls actually operate, sampling artifacts like a pentest report or an access review against what the paperwork claims.
Is Pentest Today an ISO 27001 certification body?
No. Certification is issued by an accredited certification body after its own Stage 1 and Stage 2 audit, and Pentest Today has no role in that decision. What it produces is the technical evidence — the pentest, scans, and Annex A-mapped policies — that certification body samples against.
How often does a certified company get re-audited?
A certificate runs three years, with a surveillance audit in each of the first two years and a full recertification audit at the third. Surveillance samples a subset of controls rather than all of them, but a system added since the last visit is exactly what it looks for.
How is ISO 27001 different from SOC 2 for a company doing both?
SOC 2 is an attestation over how your controls met stated criteria during a period; ISO 27001 certifies that you run an ongoing management system against Annex A, checked by stage audits and renewed by surveillance. The evidence overlaps heavily, but the artifact you hand over — a report versus a certificate — does not.
Is the pentest a real test or just a scanner dump?
Both scanning and AI triage are scoped to your approved targets, and every finding is reviewed and signed off by a human before delivery — so the report reflects verified findings, not raw scanner noise.
How fast can I get a report?
Most reports turn around in hours, not weeks. You connect an approved target, we scan and verify, and you export a client-ready report and policy pack.
Get the evidence for your ISO 27001 review this week.
Start a scan on an approved target and walk in with the report, policies, and diagrams already done.