Close your penetration testing requirement in 72 hours
Buy the test that satisfies the testing clause your framework puts on you. Run by AI, checked by people, delivered as the six documents an assessor asks for, and guaranteed to be accepted by yours.
Accepted by your assessor, guaranteed
If they will not accept our report as evidence, we join the call, change what they ask for and retest at no cost until they do.
In your hands in 24 to 72 hours
Measured from the moment scope is agreed. Not weeks of waiting for a consultant's calendar, and not a queue.
$1,900 per 10 targets
One flat price for up to 10 targets, internal or external, with retests included. Larger scopes add targets in blocks of 10.
Which framework are you being assessed against?
Pick every one that applies. We show the clauses a test helps close and the documents your assessor receives.
Whichever you pick, every test delivers the same six documents. They are what an assessor asks for, and they are yours to keep.
Findings report
Proof each finding was actually exploited
Every confirmed finding with the request and response that proves it, the steps to reproduce it, severity set against your environment, and what to change.
Methodology statement
The documented approach, as a separate document
The documented approach: the phases run, the coverage rules, how targets were selected, which tooling was used and where human judgment entered.
Scope and authorization record
What was tested, what was not, and who authorized it
The systems in scope, the systems explicitly excluded, the testing window, and the named person who authorized exploitation.
Retest and closure record
The re-run that proves a finding is closed
The dated re-run against each finding you remediated, showing whether the original exploit still reproduces.
Validation and independence statement
Who reviewed it, and how they are independent
Who reviewed the findings before release, their qualifications, what they changed, and their independence from the systems under test.
Testing history
The dated series that evidences a cadence
The dated record of every test across the period, with scope and outcome for each.
- Clauses covered
- 0
- Documents
- 0
- To your report
- 24 to 72 h
- How often
- 12 months
- 0
Findings report
Every confirmed finding with the request and response that proves it, the steps to reproduce it, severity set against your environment, and what to change.
- PCI DSS11.4.2Internal penetration testingInternal testing from inside the network, with the findings and the exploitation evidence for each one.
- PCI DSS11.4.3External penetration testingExternal testing against the internet-facing perimeter, on the same cadence and to the same methodology.
- PCI DSS11.4.5Testing of segmentation controlsTesting that attempts to cross the segmentation boundary, with the result recorded either way.
- PCI DSS11.4.6Segmentation testing, service providersThe same segmentation testing on the six-month cadence service providers are held to, evidenced by the series rather than a single report.
- PCI DSS11.4.7Multi-tenant service providersWhere you are the provider, reports you can hand to your own customers as evidence, scoped to what they are entitled to see.
- SOC 2CC4.1Monitoring of controlsA separate evaluation, performed by someone other than the people who built or run the system, checking that controls work rather than that they exist.
- SOC 2CC7.1Detection of configuration changes and new vulnerabilitiesRepeated testing across the period that surfaces newly introduced exposure, with the date of each run.
- SOC 2CC7.2Monitoring for anomaliesTesting activity your own detection should have caught, which doubles as a live check on whether your monitoring fires.
- SOC 2CC3.2Risk identification and analysisFindings with severity set against your environment, which feed your risk register as a documented input.
- ISO 27001Annex A 8.8Management of technical vulnerabilitiesInformation about technical vulnerabilities in your systems, obtained and acted on, with the remediation tracked to closure.
- ISO 27001Annex A 8.29Security testing in development and acceptanceTesting performed against applications and infrastructure before and after release, to a defined process.
- ISO 27001Annex A 8.9Configuration managementMisconfiguration found by testing the live estate rather than by reading the intended baseline.
- ISO 27001Clause 9.1Monitoring, measurement, analysis and evaluationResults you can trend across cycles, which is what the clause means by evaluating the effectiveness of the management system.
- HIPAA§164.308(a)(8)EvaluationA periodic technical evaluation of your safeguards, repeated when the environment or operations change.
- HIPAA§164.308(a)(1)(ii)(A)Risk analysisConfirmed exposure affecting health information, as a factual input to the risk analysis rather than a theoretical one.
- HIPAA§164.312(e)(1)Transmission securityTesting of how health information moves across networks, including the transport protections in place.
- NIST 800-1713.12.1 (Rev 3: 03.12.01)Periodically assess the security controlsAn assessment that determines whether controls are effective in practice, not whether they are documented.
- NIST 800-1713.11.2 (Rev 3: 03.11.02)Scan for vulnerabilities in systems and applicationsVulnerability identification across the in-scope estate, with the dated record of each run.
- NIST 800-1713.11.3 (Rev 3: 03.11.03)Remediate vulnerabilities in accordance with risk assessmentsRemediation closed out by retest, with the risk basis for the order things were fixed in.
- CMMCCA.L2-3.12.1Periodic security control assessment (Level 2)Assessment evidence for the controls in your System Security Plan, with the methodology that produced it.
- CMMCRA.L2-3.11.2Vulnerability scanning (Level 2)Identification of vulnerabilities across in-scope systems and applications, on a recorded cadence.
- CMMC800-172 3.12.1ePenetration testing (Level 3)Annual penetration testing combining automated tooling with human expertise, which is the shape this enhanced requirement describes.
- Cyber EssentialsFirewallsBoundary firewalls and internet gatewaysWhat is actually reachable from the internet, which regularly differs from what the firewall rules suggest.
- Cyber EssentialsSecure configurationSecure configurationDefault credentials, unnecessary services and exposed interfaces found on the live estate.
- Cyber EssentialsSecurity update managementSecurity update managementUnpatched software identified by version and by confirmed exploitability, not only by a version string.
- Cyber EssentialsUser access controlUser access controlWeak authentication, missing multi-factor protection and accessible administrative interfaces.
- GDPRArticle 32(1)(d)Regular testing, assessing and evaluating effectivenessA repeating testing program with dated results, which is the clause asking for exactly this and the closest the regulation comes to naming a penetration test.
- GDPRArticle 32(1)(b)Ongoing confidentiality, integrity, availability and resilienceConfirmed exposure of personal data, demonstrated rather than inferred from a configuration review.
- GDPRArticle 5(1)(f)Integrity and confidentialityEvidence of appropriate security, and of the remediation when testing shows it was not appropriate.
- GDPRArticle 35Data protection impact assessmentTechnical findings about a high-risk processing activity, as a factual input to the assessment.
- NIS2Article 21(2)(f)Policies to assess the effectiveness of risk-management measuresA documented, repeating assessment of whether your measures work, with results over time.
- NIS2Article 21(2)(e)Security in acquisition, development and maintenance, including vulnerability handlingVulnerabilities found, triaged and closed out, which is the handling half of this measure.
- NIS2Article 21(2)(a)Risk analysis and information system security policiesFindings with severity against your environment, feeding the risk analysis the article requires.
- NIS2Article 20Governance and management accountabilityReporting management can act on, and a record of what was known when, since the directive makes management personally accountable.
- DORAArticle 25Testing of ICT tools and systemsVulnerability assessments, network security assessments, gap analyses and penetration testing, with systems supporting critical functions tested at least yearly.
- Cyber insurancePolicy conditionsWarranties and conditionsContinuous evidence that a named control stayed in place through the policy period, not just at inception.
- Cyber insuranceUnderwritingLimits and termsReports and remediation evidence to hand to the broker, which is what moves terms at higher limits.
A list of things that might be wrong is a scan. An assessor looking for a penetration test wants evidence that something was actually exploited.
- 0
Methodology statement
The documented approach: the phases run, the coverage rules, how targets were selected, which tooling was used and where human judgment entered.
- PCI DSS11.4.1A defined penetration testing methodologyThe methodology statement covers the whole cardholder data environment perimeter and critical systems, testing from inside and outside, at both the network and application layer, with results retained.
- ISO 27001Annex A 8.29Security testing in development and acceptanceTesting performed against applications and infrastructure before and after release, to a defined process.
- NIST 800-1713.12.1 (Rev 3: 03.12.01)Periodically assess the security controlsAn assessment that determines whether controls are effective in practice, not whether they are documented.
- CMMCCA.L2-3.12.1Periodic security control assessment (Level 2)Assessment evidence for the controls in your System Security Plan, with the methodology that produced it.
- CMMC800-172 3.12.1ePenetration testing (Level 3)Annual penetration testing combining automated tooling with human expertise, which is the shape this enhanced requirement describes.
- GDPRArticle 32(1)(d)Regular testing, assessing and evaluating effectivenessA repeating testing program with dated results, which is the clause asking for exactly this and the closest the regulation comes to naming a penetration test.
- NIS2Article 21(2)(f)Policies to assess the effectiveness of risk-management measuresA documented, repeating assessment of whether your measures work, with results over time.
- DORAArticle 24General requirements for a digital operational resilience testing programA documented, risk-based testing program with an independent party performing the tests.
Several standards require the methodology itself as a separate artifact, not just the results. PCI DSS 11.4.1 is explicit about it.
- 0
Scope and authorization record
The systems in scope, the systems explicitly excluded, the testing window, and the named person who authorized exploitation.
- PCI DSS11.4.1A defined penetration testing methodologyThe methodology statement covers the whole cardholder data environment perimeter and critical systems, testing from inside and outside, at both the network and application layer, with results retained.
- PCI DSS11.4.2Internal penetration testingInternal testing from inside the network, with the findings and the exploitation evidence for each one.
- PCI DSS11.4.3External penetration testingExternal testing against the internet-facing perimeter, on the same cadence and to the same methodology.
- PCI DSS11.4.5Testing of segmentation controlsTesting that attempts to cross the segmentation boundary, with the result recorded either way.
- PCI DSS11.4.7Multi-tenant service providersWhere you are the provider, reports you can hand to your own customers as evidence, scoped to what they are entitled to see.
- SOC 2CC8.1Change managementTesting triggered by a material change, tying the test to the change that prompted it.
- Cyber EssentialsFirewallsBoundary firewalls and internet gatewaysWhat is actually reachable from the internet, which regularly differs from what the firewall rules suggest.
- GDPRArticle 35Data protection impact assessmentTechnical findings about a high-risk processing activity, as a factual input to the assessment.
- DORAArticle 25Testing of ICT tools and systemsVulnerability assessments, network security assessments, gap analyses and penetration testing, with systems supporting critical functions tested at least yearly.
Scope mismatch between what was tested and what the audit covers is one of the most common exceptions raised. This is the document that settles it.
- 0
Retest and closure record
The dated re-run against each finding you remediated, showing whether the original exploit still reproduces.
- PCI DSS11.4.4Correct and retest exploitable findingsA dated retest against each remediated finding, recording whether the original exploit still reproduces.
- ISO 27001Annex A 8.8Management of technical vulnerabilitiesInformation about technical vulnerabilities in your systems, obtained and acted on, with the remediation tracked to closure.
- HIPAA§164.308(a)(1)(ii)(B)Risk managementEvidence that identified risk was reduced, by way of a retest that no longer reproduces the finding.
- NIST 800-1713.11.3 (Rev 3: 03.11.03)Remediate vulnerabilities in accordance with risk assessmentsRemediation closed out by retest, with the risk basis for the order things were fixed in.
- Cyber EssentialsSecurity update managementSecurity update managementUnpatched software identified by version and by confirmed exploitability, not only by a version string.
- GDPRArticle 5(1)(f)Integrity and confidentialityEvidence of appropriate security, and of the remediation when testing shows it was not appropriate.
- NIS2Article 21(2)(e)Security in acquisition, development and maintenance, including vulnerability handlingVulnerabilities found, triaged and closed out, which is the handling half of this measure.
- DORAArticle 25(2)Remediation of findingsFindings prioritized and closed out, with the retest that proves closure.
- Cyber insuranceUnderwritingLimits and termsReports and remediation evidence to hand to the broker, which is what moves terms at higher limits.
A finding is not closed because a change was made. It is closed when the retest fails to reproduce it, which is a document, not an assertion.
- 0
Validation and independence statement
Who reviewed the findings before release, their qualifications, what they changed, and their independence from the systems under test.
- SOC 2CC4.1Monitoring of controlsA separate evaluation, performed by someone other than the people who built or run the system, checking that controls work rather than that they exist.
- CMMC800-172 3.12.1ePenetration testing (Level 3)Annual penetration testing combining automated tooling with human expertise, which is the shape this enhanced requirement describes.
- DORAArticle 24General requirements for a digital operational resilience testing programA documented, risk-based testing program with an independent party performing the tests.
- Cyber insuranceClaimsPost-incident scrutinyA consistent record showing the posture you described at underwriting was accurate, which is what gets examined after a loss.
Where a standard asks for a qualified and independent tester, this is the evidence. It is also the answer to "was this just a tool running on its own".
- 0
Testing history
The dated record of every test across the period, with scope and outcome for each.
- PCI DSS11.4.2Internal penetration testingInternal testing from inside the network, with the findings and the exploitation evidence for each one.
- PCI DSS11.4.3External penetration testingExternal testing against the internet-facing perimeter, on the same cadence and to the same methodology.
- PCI DSS11.4.6Segmentation testing, service providersThe same segmentation testing on the six-month cadence service providers are held to, evidenced by the series rather than a single report.
- SOC 2CC7.1Detection of configuration changes and new vulnerabilitiesRepeated testing across the period that surfaces newly introduced exposure, with the date of each run.
- SOC 2CC7.2Monitoring for anomaliesTesting activity your own detection should have caught, which doubles as a live check on whether your monitoring fires.
- SOC 2CC8.1Change managementTesting triggered by a material change, tying the test to the change that prompted it.
- ISO 27001Annex A 8.16Monitoring activitiesRepeated testing across the certification cycle, evidencing a monitoring activity that actually operates.
- ISO 27001Clause 9.1Monitoring, measurement, analysis and evaluationResults you can trend across cycles, which is what the clause means by evaluating the effectiveness of the management system.
- HIPAA§164.308(a)(8)EvaluationA periodic technical evaluation of your safeguards, repeated when the environment or operations change.
- HIPAANPRM, 27 Dec 2024Proposed explicit testing requirementTesting at the twelve-month cadence the proposed rule would require, so a change in the rule does not change what you do.
- NIST 800-1713.12.1 (Rev 3: 03.12.01)Periodically assess the security controlsAn assessment that determines whether controls are effective in practice, not whether they are documented.
- NIST 800-1713.12.3 (Rev 3: 03.12.03)Monitor security controls on an ongoing basisContinuous rather than annual testing, which is what ongoing monitoring of control effectiveness looks like as evidence.
- NIST 800-1713.11.2 (Rev 3: 03.11.02)Scan for vulnerabilities in systems and applicationsVulnerability identification across the in-scope estate, with the dated record of each run.
- CMMCCA.L2-3.12.3Continuous monitoring of controls (Level 2)An ongoing testing series rather than a single annual event, which is the harder half of this practice to evidence.
- CMMCRA.L2-3.11.2Vulnerability scanning (Level 2)Identification of vulnerabilities across in-scope systems and applications, on a recorded cadence.
- GDPRArticle 32(1)(d)Regular testing, assessing and evaluating effectivenessA repeating testing program with dated results, which is the clause asking for exactly this and the closest the regulation comes to naming a penetration test.
- NIS2Article 21(2)(f)Policies to assess the effectiveness of risk-management measuresA documented, repeating assessment of whether your measures work, with results over time.
- NIS2Article 20Governance and management accountabilityReporting management can act on, and a record of what was known when, since the directive makes management personally accountable.
- DORAArticle 24General requirements for a digital operational resilience testing programA documented, risk-based testing program with an independent party performing the tests.
- DORAArticle 25Testing of ICT tools and systemsVulnerability assessments, network security assessments, gap analyses and penetration testing, with systems supporting critical functions tested at least yearly.
- Cyber insuranceApplicationThe proposal formA dated testing record that matches the frequency you declared, since the answer is a representation the policy is written on.
- Cyber insurancePolicy conditionsWarranties and conditionsContinuous evidence that a named control stayed in place through the policy period, not just at inception.
- Cyber insuranceClaimsPost-incident scrutinyA consistent record showing the posture you described at underwriting was accurate, which is what gets examined after a loss.
A cadence you committed to is evidenced by the series, not by the latest report. This is what a SOC 2 Type II observation window actually needs.
PCI DSS v4.0
Names penetration testingInternal and external testing at least every 12 months and after every significant change, against a documented methodology, with exploitable findings corrected and retested.
Applies to: Anyone who stores, processes or transmits payment card data.
SOC 2
Expected, not namedWhatever cadence your own system description commits to. Most commit to annual, and are then audited against that commitment.
Applies to: Service organizations proving security to customers, usually on request from enterprise buyers.
ISO/IEC 27001:2022
Expected, not namedNo fixed cadence in the standard. Your own risk assessment and Statement of Applicability set the frequency, and the certification body audits you against what you wrote.
Applies to: Organizations certifying an information security management system, often to win regulated or enterprise business.
HIPAA Security Rule
Proposed, not yet in forceA periodic evaluation on a cadence your risk analysis justifies, plus re-evaluation when the environment changes. Annual is the common reading.
Applies to: Covered entities and business associates handling electronic protected health information in the United States.
NIST SP 800-171
Expected, not namedPeriodic assessment of your security controls, on a frequency you define and can defend. Testing is how the assessment requirement is commonly met.
Applies to: Contractors handling controlled unclassified information for United States federal agencies.
CMMC 2.0
Expected, not namedLevel 2 requires periodic assessment of the 800-171 controls. Level 3 adds an explicit annual penetration testing requirement drawn from NIST SP 800-172.
Applies to: United States defense contractors and their supply chain, at the level their contract specifies.
Cyber Essentials
Expected, not namedAnnual certification against five technical controls. Testing is not the certification, but it is how you find out whether you would pass before you apply.
Applies to: United Kingdom organizations, frequently required to bid for public sector contracts.
GDPR
Names penetration testingA process for regularly testing the effectiveness of your security measures. The regulation requires the process and leaves the frequency to you.
Applies to: Anyone processing personal data of people in the European Union or the United Kingdom.
NIS2
Expected, not namedPolicies and procedures to assess whether your risk-management measures are effective. The directive requires the assessment and sets no interval.
Applies to: Essential and important entities in named European Union sectors, as transposed by each member state.
DORA
Names penetration testingA testing program covering the full range of assessments, with testing of systems supporting critical functions at least yearly.
Applies to: European Union financial entities and their critical technology providers.
Cyber insurance
Set commercially, not by a standardWhatever you declared on the application. Annual is the most commonly declared answer, and therefore the most commonly broken commitment.
Applies to: Anyone buying or renewing a cyber policy, at any size.
What we cannot do for you
- PCI DSSA Report on Compliance or a Self-Assessment Questionnaire is signed by a Qualified Security Assessor or by you, never by a testing provider. We produce the testing evidence your assessor reviews.
- SOC 2The SOC 2 opinion itself comes from a licensed CPA firm. We produce the testing evidence inside your observation window; your auditor decides whether it satisfies the criteria.
- ISO 27001Certification is issued by an accredited certification body after its own audit. Nothing a testing provider produces shortens or replaces that audit.
- HIPAAThe explicit twelve-month testing requirement is a proposal, not current law. Anyone telling you HIPAA mandates a penetration test today is overstating the rule as it stands.
- NIST 800-171Revision 2 numbering is what most contracts and assessments still reference; Revision 3 renumbers the same requirements. Both numbers appear above so neither reading is ambiguous.
- CMMCLevel 2 certification is assessed by an authorized third-party assessment organization, and Level 3 by the Defense Industrial Base Cybersecurity Assessment Center. We supply testing evidence for that assessment; we cannot perform or substitute for it.
- Cyber EssentialsCyber Essentials is a self-assessment verified by a certification body, and Cyber Essentials Plus requires a hands-on audit by a licensed assessor. Our testing prepares you for either and replaces neither.
- GDPRNo regulator certifies GDPR compliance, and no report makes you compliant. Testing evidence supports the accountability obligation; it does not discharge it.
- NIS2NIS2 applies through each member state's own transposition, and national rules differ on scope, deadlines and supervision. Check the law in your country, not the directive alone.
- DORAThreat-led penetration testing under Articles 26 and 27 is a separate regime: testers must meet formal criteria, and the exercise is run to the TIBER-EU framework under supervisory oversight. We cover Article 25 testing. We do not represent ourselves as accredited threat-led testers.
- Cyber insuranceNo testing provider can bind coverage or guarantee a premium outcome. Carriers weigh testing alongside multi-factor authentication, endpoint protection and recovery capability.
Between tests, UTMStack scores these frameworks from your own logs, control by control. See how compliance works. Still weighing it up? Talk to us first.
Why this costs less and arrives sooner
Four reasons, and only one of them is price. The others are why teams who could afford a consultancy still move.
The evidence stops going stale
A once-a-year test is accurate on the day it is written and drifts from that day onward, while your systems keep changing. Because a test here takes days and has a known price, testing every quarter or after each release becomes practical, and a dated series of results is what several standards ask you to show.
Days instead of a booking slot
Most of the delay in a traditional test is not the testing. It is waiting for a slot, agreeing on scope by email, and waiting again for the write-up. Here testing starts when scope is agreed and the documents are written as the test runs. That matters for the trigger people forget: several frameworks make a significant change its own reason to test, whatever the calendar says.
People still decide what counts
Every finding is reproduced on a second, independent pass before it reaches your report. One that reproduces is confirmed, with severity set by a qualified tester against your environment. One that does not is kept as informational with the limitation stated, rather than reported as confirmed or quietly dropped. Exploitation itself waits for a named person on your side to authorize it, and that authorization is recorded in the scope document.
A price you know before you ask
Consultancies price each test after a scoping call, which is why the second test of the year rarely happens. Here it is $1,900 for every 10 targets, internal or external, so testing after a release is a number you already know. Send us your last quote and its scope, and we will tell you plainly what the same coverage costs here.
Read a real report before you buy
Both came out of a deliberately vulnerable test environment, unedited. They are the fastest way to judge whether the evidence would satisfy the person who reviews yours, and the right thing to forward to them if you want to check first.
Web application test
A deliberately vulnerable shop application, tested end to end, with exploitation evidence for each confirmed finding.
Open the sample report (PDF, 2.7 MB)Classic vulnerability set
A well-known training target, useful for comparing our findings against a baseline you may already know well.
Open the sample report (PDF, 2.4 MB)
The questions people actually ask
Will an auditor accept a penetration test that was run by AI?
Auditors judge whether the evidence is sufficient, not which tool produced it. They look for a documented methodology, a scope that matches the system being assessed, findings with proof that something was actually exploited rather than merely detected, a qualified and independent reviewer, and a record of fixes and retests. Every test delivers those as separate documents for that reason. We also guarantee it: if your assessor will not accept our report as evidence for the control it was produced for, we join the call, change what they ask us to change, and retest at no cost until they do.
What does the acceptance guarantee cover, and where does it stop?
It covers our work being accepted as testing evidence for the control it was produced for. If your assessor will not accept it, we do three things at no extra cost: join a call with you and them to explain the methodology in their terms, make whatever changes to scope, depth or documentation they ask for, and run the test again and reissue the documents. That repeats until they accept it. It stops there: we do not promise you pass your audit, because most outcomes turn on controls a penetration test never touches. If the gap your assessor finds is something testing cannot close, we tell you rather than retest forever.
How much does a penetration test cost?
$1,900 for up to 10 targets, internal or external. Larger scopes are priced in blocks of 10: 11 to 20 targets cost $3,800, and 25 targets cost $5,700. Every test includes all six evidence documents, human validation of each finding and retests until the findings you fix are closed.
What counts as a target?
One thing we test: a web application, an API, a subnet, a firewall or VPN gateway, or a server. Internal and external targets count the same. Tell us what you have and we will count the targets with you before the test starts, so the price is settled up front.
Is the 24 to 72 hour delivery a real commitment?
Yes, measured from the moment scope is agreed and your targets are reachable, not from the moment you contact us, because we will not test anything until we are sure you are authorized to have it tested. Most tests land at the shorter end. The range exists because a larger estate, an internal network or segmentation testing takes longer to cover properly than a single external application. If we are going to miss it, you hear from us before the deadline rather than after.
Is this a real penetration test or a vulnerability scan?
They are different activities, and some standards separate them explicitly: PCI DSS puts scanning in Requirement 11.3 and penetration testing in 11.4, and scan output does not satisfy 11.4. A scanner reports what matched a signature. Our tests go further: they authenticate, chain findings together into attack paths and attempt exploitation to establish what an intruder could actually reach. Exploitation waits behind a human authorization, because that is the point where testing stops observing and starts acting.
Who validates the findings, and what do they change?
Findings are reproduced on a second, independent pass before they reach your report. A finding that reproduces is confirmed, with severity set by a qualified tester against your environment rather than by a generic score. A finding that does not reproduce is kept as informational with the limitation stated openly. The validation and independence statement names who did that review and what they changed, which is the document an assessor asks for when they want to know a person was involved.
How often should we test?
As often as your framework asks, and after every significant change. Pick your frameworks above to see the cadence each one sets: PCI DSS, DORA and the proposed HIPAA rule point to at least every 12 months, while SOC 2, ISO 27001 and GDPR leave it to what you commit to. A cadence is proven by the dated series of tests, which is what a SOC 2 Type II observation window and a cyber insurance renewal both need.
Is it safe to run against production?
Scope is enforced at every step of the test rather than by a setting someone can forget: a target that is not in the agreed scope is refused before any request reaches the network. Exploitation does not begin until a named person authorizes it, and that authorization is recorded in the scope document. Post-exploitation shows what is reachable without taking your data. If you would rather not test production at all, we can run the test from a server you control.
Close the requirement this week
Tell us what you need tested and which framework it is for. We confirm scope and price within one business day, and the report is in your hands 24 to 72 hours after scope is agreed.