Compliance & Audit Readiness
Independent testing and the evidence behind it, scoped to your SOC 2, ISO 27001, PCI DSS or HIPAA boundary. We do not certify; we give your assessor what they need to sign off.
Frameworks ask for independent testing, but assessors send reports back for predictable reasons: the scope does not match the system description, the methodology is missing, the findings have no remediation evidence, or the retest was never done. Each of those becomes an exception or a delay, and none of them has anything to do with how secure you actually are.
We start from the boundary your assessor will examine, whether that is the SOC 2 system description, the ISO 27001 scope statement or the PCI cardholder data environment, and test exactly that. The report states the methodology, dates and scope in the form assessors look for, maps each finding to the control it affects, and closes with a retest. We do not issue certifications; we work alongside whoever signs off.
Usually, one of these is true
- Your SOC 2 Type II observation window has started and the auditor wants a penetration test of the in-scope system before fieldwork.
- A PCI DSS assessment needs internal, external and segmentation testing of the cardholder data environment, and last year's report no longer matches the network.
- An ISO 27001 surveillance audit is coming and your only evidence of technical vulnerability management is a scanner export.
- A hospital or payer customer wants proof that your HIPAA security evaluation included independent technical testing of the systems holding patient data.
What we test and document
Scope follows the boundary your assessor will examine, not a list of hostnames. Where the framework names a specific kind of test, such as PCI DSS segmentation testing, that test is scoped in by name.
- Scope alignment. In-scope systems, data flows and third parties reconciled against your system description, Statement of Applicability or cardholder data flow diagram, so nothing the assessor expects is missing from the test.
- Applications and APIs. Web applications and APIs inside the audit boundary tested by hand for broken authorisation, injection, session handling and business-logic flaws, against OWASP ASVS.
- Infrastructure and cloud. External and internal network testing and a cloud configuration review of the in-scope environment, including the administrative access paths an assessor will ask about.
- Segmentation testing. Where PCI DSS applies, testing from each segment you declare out of scope to prove it genuinely cannot reach the cardholder data environment.
- Control mapping. Each finding tied to the criteria or controls it affects, such as SOC 2 CC7.1, ISO/IEC 27001 Annex A 8.8 or PCI DSS Requirement 11.4, so the assessor does not have to translate it.
- Remediation and retest. Findings tracked to a clean retest before the assessor needs the evidence, so the report closes with remediation shown rather than an open list.
How the engagement runs
It runs backwards from the date your assessor needs evidence, so testing, fixes and the retest all land inside that window.
- Boundary and deadline. We read your system description, scope statement or network diagrams, confirm the audit timeline, and agree scope, rules of engagement, a fixed price and fixed dates in writing.
- Assessor check. If you want it, we share the scope and methodology with your auditor or QSA before testing starts, so any disagreement about coverage comes up early.
- Testing. Manual testing of the agreed scope. Findings reach your channel as they are confirmed, and criticals within the hour, so fixes can start while testing continues.
- Fix and retest. Your team fixes; we retest each finding against its original reproduction and record the result, including anything you formally accept as a risk.
- Evidence pack. The final report, control mapping and letter of attestation are issued against the retested state, and the testing engineer joins the assessor's call if questions come up.
What you get
- Penetration test report. Scope, dates, methodology, a statement of independence and every finding with its reproduction, CWE and CVSS v4.0 rating, written for the assessor and your engineers at once.
- Control mapping. A table tying each finding to the framework criteria or controls it affects, for whoever maintains your compliance evidence.
- Retest results. The status of each finding after fixes, with evidence, so the assessor sees remediation rather than an open list.
- Letter of attestation. A short letter confirming what was tested, when, and its state after the retest, for customers and assessors who do not need the full report.
- Assessor support. The engineer who did the testing, on the call when your auditor or QSA has questions about scope, method or a specific finding.
What we need from you
- Your SOC 2 system description, ISO 27001 scope and Statement of Applicability, or PCI DSS network and cardholder data flow diagrams, whichever apply.
- The audit timeline: the observation window, fieldwork dates and the date the assessor needs the report.
- Test accounts for every role inside the boundary, and a foothold in each network segment that segmentation testing has to start from.
- A contact at your audit firm or QSA, if you want the scope checked with them before testing.
- Previous test reports and any formally accepted risks, so the new report shows what changed since the last assessment.
What we can show you
- We test, we do not certify. We produce the independent testing and evidence and work alongside whoever signs off. The people testing you are never the people issuing your certificate or report.
- The tester writes the report. The engineer who found each issue writes it up and answers the assessor's questions about it. There is no report writer in between who was not there.
- Retest and attestation included. A retest after fixes land and a letter of attestation are part of the engagement, so the evidence closes instead of carrying open findings into fieldwork.
- Used to regulated work. More than 50 engagements, including for security leads at banks and health networks, where a report has to satisfy an assessor as well as an engineer.
Standards we work to
These are the frameworks the testing and control mapping are built around; for any other framework the method stays the same and only the mapping changes.
- SOC 2 (AICPA TSC)
- ISO/IEC 27001:2022
- PCI DSS v4.0.1
- HIPAA Security Rule
- GDPR Article 32
- NIST SP 800-115
- OWASP ASVS
Common questions
Can you certify us or issue our SOC 2 report?
No. SOC 2 reports are issued by licensed CPA firms, ISO 27001 certificates by accredited certification bodies, and PCI DSS reports on compliance by Qualified Security Assessors. We produce the independent testing and evidence those assessors rely on, and we work alongside whoever signs off.
Will our auditor accept your report?
Acceptance is the assessor's decision, so we remove the usual reasons for rejection: scope that matches the audit boundary, a stated methodology and dates, a statement of independence, findings mapped to controls, and a completed retest. If you want certainty up front, we share the scope and methodology with your auditor before testing starts.
When should testing happen relative to our audit?
Early enough that fixes and the retest finish before the assessor needs evidence. For a SOC 2 Type II that means inside the observation window with room left before fieldwork; for PCI DSS, within the interval the standard sets and after any significant change. We plan the dates backwards from your audit timeline.
Do you test segmentation for PCI DSS?
Yes, when PCI DSS is in scope. We test from each segment you declare out of scope and try to reach the cardholder data environment, then record which paths are closed and which are not. A segmentation failure is reported like any other finding, with the path reproduced.
Will you go through our vendor security review first?
Yes. Mutual NDA and PGP are in place before anything is shared, and we complete your vendor security questionnaire during onboarding. Evidence is encrypted, limited to the engineers on the engagement and destroyed after the retest on request.
Related services
Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.