Gap assessment
A clear picture of where you stand today against your target framework.
- Control-by-control scoring
- Prioritised remediation plan
- Effort and cost estimates
Pass the audit because you are secure, not the other way round. We map your posture against the framework you report against - ISO 27001, PCI DSS, SOC 2, Saudi Arabia's NCA ECC, SAMA, Abu Dhabi's ADHICS or the State Bank of Pakistan's technology framework - close the gaps that matter, and produce the evidence auditors accept.
Most teams discover their gaps three weeks before the audit. We work the other way round: one assessment shows where you stand against every framework you care about, so remediation is planned instead of panicked.
Because the same team also does your penetration testing, the technical evidence auditors ask for is produced as part of the work rather than scrambled together at the end.
We join at whatever stage you are at.
A clear picture of where you stand today against your target framework.
We work alongside your team to close gaps and build the evidence pack.
We sit with you through the external audit and answer the technical questions.
We agree which frameworks apply, which systems are in scope, and what your deadline is.
A single assessment scores you against every control, technical and organisational.
We prioritise gaps by risk and effort, then support your team in closing them.
We assemble the evidence pack and run a dry-run audit so there are no surprises.
We support you through the external audit and set up the rhythm that keeps you compliant.
Reports your board and your engineers can both use. No 400-page scanner dump.
Tell us about your systems and we will recommend the right assessment, with a clear scope and a fixed price.
Testing is remote work by nature. We scope on a call, test under a signed agreement and rules of engagement, and report inside your working hours - our day overlaps with the US morning. What changes from country to country is not the testing. It is the clause your report has to satisfy, and whether we are allowed to do the work at all, which we will tell you before you ask.
Where most of this work is bought, and where most of our enquiries now come from. Three things drive it. SOC 2 Type II: the criteria do not name a penetration test, but it sits in the points of focus under CC4.1 and auditors expect one inside the observation window. PCI DSS v4.0.1: 11.4.3 external and 11.4.2 internal testing at least annually, 11.4.6 every six months for service providers - and the tester does not have to be a QSA. The FTC Safeguards Rule: 16 CFR 314.4(d)(2)(i) requires annual penetration testing of any non-bank financial institution without continuous monitoring.
If you hold a NYDFS licence, 23 NYCRR 500.05(a) is explicit: penetration testing from inside and outside your system boundaries, by a qualified internal or external party, at least annually. The Second Amendment finished phasing in on 1 November 2025. California’s CCPA cybersecurity audit regulations took effect on 1 January 2026 and list penetration testing among the things the auditor assesses.
English-speaking, used to buying testing from outside their own borders, and driven by the same two things: ISO 27001 certification and the security questionnaire an enterprise customer sends before signing. We take private-sector work in all three. We do not take UK public sector or critical national infrastructure work, which is gated behind NCSC CHECK.
Where we started, and still a real part of the business. Abu Dhabi healthcare works to ADHICS V2 (yearly). Saudi entities under the NCA’s ECC 2:2024 test periodically, or six-monthly for critical systems. SAMA requires annual testing of customer and internet-facing services. UAE licensed financial institutions came under the Central Bank’s C 1/2026 on 14 September 2026. Our office and our academy are in Karachi.
We are a Pakistani company. Some US work is closed to a firm like ours, and you should hear that from us rather than from your own legal team three weeks in.
Everything else is paperwork, and we keep it ready rather than assembling it after you ask: a mutual NDA, a W-8BEN-E, the testers’ names and certification numbers, a redacted sample report, and a data-handling note saying what we hold and when it is destroyed.
Not sure which of these applies to you? The compliance and audit page sets out what each framework actually asks for, side by side.
Most of the confusion in compliance work comes from assuming every framework demands the same thing. They do not. This is what each one actually asks for, taken from the issuing body’s own document.
| Framework | Who it applies to | What it asks for |
|---|---|---|
| PCI DSS v4.0.1 | Anyone who stores, processes or transmits card data | Internal and external penetration tests at least once every 12 months and after any significant change (Requirement 11.4). Segmentation testing every 12 months, or every six months for service providers. |
| ISO/IEC 27001:2022 | Any organization certifying its information security management system | Technical vulnerability management (A.8.8) and security testing in development and acceptance (A.8.29). The standard never names penetration testing - it is simply how most organizations evidence those controls. |
| SOC 2 | SaaS platforms and service providers reporting to US customers | Penetration testing is a point of focus under CC4.1, not a criterion in its own right. In practice almost every auditor expects to see one. |
| NCA ECC 2:2024 - Saudi Arabia | Government bodies, their affiliates, and private operators of critical national infrastructure | Penetration testing conducted periodically, with a scope that must include every service provided over the internet (subdomain 2-11). |
| NCA CSCC 1:2019 - Saudi Arabia | Critical systems inside those same entities | Penetration tests at least once every six months, and vulnerability assessments at least monthly. |
| SAMA Cyber Security Framework | Banks, insurers, finance companies and market infrastructure regulated by the Saudi Central Bank | Customer and internet-facing services reviewed and penetration tested annually (section 3.2.4). A separate SAMA framework asks financial entities for an ethical red-teaming exercise at least once every three years. |
| ADHICS V2 - Abu Dhabi | Healthcare entities in Abu Dhabi and the providers that serve them | A yearly schedule of vulnerability assessment and penetration testing (control CO 7.1), plus independent technical assessment and an annual independent audit. |
| CBUAE Operational Risk Management Regulation | Financial institutions licensed in the UAE, in force since 14 September 2026 | Periodic testing of at least the critical functions, which must include penetration testing by an independent third party, with the results presented to the Board (article 7.14). |
| UAE Information Assurance Standard v2 | UAE federal and emirate government entities and critical infrastructure operators | The national information assurance controls, issued by the UAE Cyber Security Council. Dubai government entities additionally work to the Dubai Electronic Security Center’s Information Security Regulation. |
| Qatar National Information Assurance Policy | Government, semi-government and private entities in Qatar | An annual security assurance plan, which the policy says may be built from activities such as penetration testing, security procedure audits and incident scenario testing. |
| SBP Enterprise Technology Governance framework | Banks, DFIs and microfinance banks in Pakistan | Periodic vulnerability assessment and penetration testing, with the interval set in the institution’s own policy, plus testing at the time of any major system update (section 2.7(b)). |
Frameworks are revised. We check the current text of the one you report against at the start of every engagement rather than working from the version we saw last year.
No, and you should be wary of anyone who says they can. Certification must come from an accredited independent auditor. We get you ready, produce the evidence, and support you through their audit.
For a small to mid-sized company starting from scratch, three to six months is realistic. A gap assessment in the first two weeks gives you a firm timeline rather than a guess.
Most frameworks expect independent technical testing, and PCI DSS requires it explicitly. Since we do both, your test results drop straight into the evidence pack.
Certification is not the finish line. Surveillance audits, annual testing and continuous monitoring keep it valid, and we can run that rhythm with you.
Not in those words. ISO/IEC 27001:2022 requires technical vulnerability management (control A.8.8) and security testing in development and acceptance (A.8.29). Penetration testing is not named anywhere in the standard. It is, however, the usual way organizations demonstrate those controls, and most auditors will ask what testing you have done.
PCI DSS v4.0.1 requires internal and external penetration tests at least once every 12 months and after any significant infrastructure or application change. Where segmentation is used to reduce scope, segmentation testing is required every 12 months, and every six months for service providers.
ECC 2:2024 asks for penetration testing to be conducted periodically, with a scope that must cover every service you provide over the internet. If any of your systems are classified as critical, the Critical Systems controls raise that to at least once every six months, with vulnerability assessments at least monthly.
No, and be careful with anyone who says they can. A certification body issues the certificate and must be independent of the people who prepared you for it. We do the readiness work, the gap assessment, the technical testing and the evidence pack, then hand you to the auditor in a state where the audit is uneventful.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.