The SOC 2 Type 1 report went through on a single pentest. A Type 2 auditor works differently. Over a window of several months, they pick findings from that report and ask what happened to each one, when it was fixed, and who checked that the fix held. ISO 27001 surveillance audits ask the same questions every year. This guide explains why that changes what a pentest has to prove, and how a gray box test followed by a 90-day remediation window builds the record auditors and enterprise buyers read.
Quick Answers
How does remediation testing support SOC 2 Type 2?
Type 1 looks at security controls on a single date. Type 2 checks that they kept working across a period, usually 3 to 12 months. Remediation testing, where testers re-run the original attack on each finding your team fixed, gives every finding a dated trail from report to verified fix. Auditors sample from that trail.
Does ISO 27001 require a retest?
No rule names one. Clause 10.2 expects a company to review whether each corrective action worked, and the auditor checks that record at every surveillance audit (the yearly check-in during the three-year certificate). A retest report covers that check in one document.
Is a black box pentest enough for compliance?
It can sometimes carry a Type 1. For Type 2 it rarely holds up. Many breaches start with a stolen or phished password, so a test that begins with no login never reaches the part of the app the auditor is describing. Gray box testing gives the testers a login for each user role and starts where attackers do.
Why One Report Stops Being Enough
A pentest report is accurate on the day it’s delivered. It lists what the testers broke and how badly. What it can’t show is what happened next, and at the Type 2 and ISO 27001 level, that second part is what gets audited. A Type 2 report describes how security behaved across months, not how it looked on one day.
For a company that wants the test to change something, the change can be measured. By the end of the window, the critical and high findings from the report should be closed, and any still open should have a documented reason. The time from report to verified fix should shrink from one test to the next. Nothing marked fixed should turn up again in the following test, since a repeat finding is the kind of pattern auditors notice.
SOC 2 Type 1 vs Type 2: Where Remediation Comes In
SOC 2 is an audit report from an independent CPA firm, built on the AICPA’s Trust Services Criteria, that tells customers how a company protects their data. A Type 1 report confirms the controls were designed sensibly and in place as of one date. One pentest report can carry that, since it shows the company has a way to find vulnerabilities.
Type 2 is where the auditor starts following findings. The observation period usually runs 3 to 12 months, shorter for a first report and a full year for renewals, and the auditor samples evidence from across all of it. Say the pentest in month two found a high-rated access-control flaw. Later in the period, the auditor picks that finding and asks for the ticket, the change that fixed it, and proof that someone confirmed the fix worked. A ticket marked “closed” with nothing behind it doesn’t answer the last part. A dated retest from the testing firm, tied to that finding, does.
| Type 1 | Type 2 | |
| Time covered | One date | Usually 3 to 12 months |
| What the auditor checks | Controls exist and are designed well | Controls kept working all period |
| What one pentest shows | A process for finding vulnerabilities | Not enough on its own |
| What gets asked about findings | That they were found and assigned | When each was fixed and how the fix was verified |
Gaps turn into exceptions, the auditor’s term for a control that didn’t operate as described. One exception rarely sinks a report. It does stay in the document every enterprise buyer reads during vendor review for the next year.
SOC 2 doesn’t require a pentest. Criterion CC4.1 lists penetration testing as one way to evaluate whether controls work, and Type 2 auditors still expect to see what became of the findings. The anatomy of an audit-ready SOC 2 pentest report covers what the report itself should contain.
ISO 27001: A Yearly Check on Whether Fixes Worked
If you hold ISO 27001, the improvement question comes back every year. The certificate lasts three years, and the certification body (the accredited firm that issues it) returns for a surveillance audit in each of the two years between. Each visit looks back over the last twelve months.
The standard doesn’t require a pentest by name. Its control checklist, Annex A, covers technical vulnerabilities (A.8.8) and security testing during development (A.8.29), and pentest results are the usual evidence for both. The pull toward retesting comes from the main clauses. Under clause 10.2, when something goes wrong, the company has to correct it, find the cause, and then review whether the correction worked. A pentest finding fits that pattern closely, and the retest is the review. Clause 9.3 has top management review the security program at planned intervals, and pentest results usually feed that meeting, so leadership sees the trend as well.
Over a few years, the reports start to tell a story. Fewer highs in year two than in year one is the continual improvement clause 10.1 asks for. A finding fixed last spring that reappears this spring looks like a corrective action that failed, and the auditor will want to know why.
Companies holding both SOC 2 and ISO 27001 can usually run one engagement for both, as long as the findings are mapped to each framework. CYBRI’s ISO 27001 penetration testing page covers that mapping.
Why the Test Should Start With a Stolen Login
Once an attacker has one employee’s password, the login page stops being the boundary. Usually that password wasn’t cracked. It was reused from an old breach or typed into a convincing phishing email.
A gray box test starts from the same place. The testers get a login for each user role and try what an attacker holding it would try, such as reading another customer’s records or giving their own account admin rights. Those access-control flaws live behind the login, and they’re the findings auditors and buyers care about most.
A black box test starts from nothing, like a stranger on the internet. It works as a perimeter check, and some companies get through an early Type 1 with one. For Type 2, the logged-in system in the audit scope goes mostly untested, which leaves little to retest or show improving. The gray box testing guide covers the cost side.
The 90-Day Window: Where the Evidence Comes From
The remediation window is the part of the engagement an auditor follows most closely. On compliance work it usually runs about 90 days after the report, with testers available to your team while fixes go in and a retest once they’re ready. The guide to remediation testing explains how retests catch partial fixes, and how findings that can’t be fixed in time get documented as accepted risk.
| When | What happens | What it adds to the record |
| Testing, 1 to 3 weeks | Gray box test across user roles; critical issues flagged the same day | A dated baseline of what was open |
| Report delivered | Findings rated by severity and mapped to SOC 2 and ISO 27001 | The starting point the auditor compares against |
| First month or two | Critical and high findings fixed first | Each fix logged with a date |
| Later in the window | Remaining fixes go in, then the retest | Each fix verified; partial fixes sent back |
| Day 90 | Updated report | A before-and-after document for the auditor and buyers |
By the close, the evidence sits in one place: the original report, a dated record of each fix and retest, and an updated report showing where every finding ended up. Anything still open carries a signed risk acceptance.
Time the test so the window closes before the Type 2 period ends or the ISO surveillance audit begins. Continuous penetration testing covers how often to repeat the cycle.
Remediation Testing for Compliance With CYBRI
If the report is headed to a Type 2 auditor or an ISO 27001 surveillance audit, the test gets planned backward from that date so the full remediation window fits before it. A CYBRI compliance pentest starts with scoping that matches the system in your SOC 2 description or ISO 27001 scope, so the report and the audit cover the same product. Testers log in as each of your user roles and work manual-first, the way an attacker holding a stolen password would. After the report lands, the same testers stay on hand while your team fixes, retest the fixes, and send back anything only partly fixed. Remediation testing is part of the quote, so the retest is planned and priced from the start. The window closes with an updated report showing each finding’s original severity and where it ended up, ready for the evidence pack. On ongoing programs, the Blue Box platform tracks findings and retests from one test to the next, so the year-over-year trend sits in one place.
Every compliance engagement includes:
- Senior, OSCP-certified testers working manual-first
- Gray box testing by default, with a login for every user role in scope
- Same-day alerts for critical issues, ahead of the final report
- A two-part report: a plain-language summary for leadership and the auditor, plus technical findings scored on CVSS 4.0 (the standard severity scale) with steps to fix each one
- Findings mapped to SOC 2 and ISO 27001, and to HIPAA or PCI DSS where they apply
- Remediation support, with testers answering your engineers’ questions while fixes go in
- A retest inside the 90-day remediation window
- An updated report at the close of the window for your auditor and customers
- A walkthrough call with the testers after delivery
To plan a test around your audit dates, contact CYBRI.
Frequently Asked Questions
Can a pentest from before the Type 2 window count?
Usually not on its own. The auditor is checking how controls worked during the period, and a report dated before it says little about that time. Its findings can still help if they were fixed and retested inside the window.
What happens if a finding can’t be fixed before the window closes?
It gets documented. An authorized person signs off on accepting the risk, with a reason and a date to review it, and the updated report lists the finding as open. Auditors handle a documented decision far better than an open finding nobody explained. The guide to remediation testing covers how accepted risk works.
How much does it cost, and how long does it take?
Price follows scope: the number of apps, APIs, user roles, and cloud environments in the test. CYBRI quotes each engagement after a short scoping call, and the pricing page shows current starting points. Testing takes 1 to 3 weeks, followed by the 90-day remediation window.
Plan the Test Around Your Audit Window
Bring your audit dates to the first call: when the Type 2 period opens, or when the surveillance audit is booked. The call works backward from there to set the test date and size the scope, leaving the full window for fixes and retests before the auditor arrives. Book a scoping call with CYBRI.
