Compliance readiness, and the evidence that survives the audit.
Fourteen frameworks, one question each: where do you actually stand, control by control? We run the readiness engagement, work the gap list down with your team, and produce the independent testing evidence your assessor asks for. Then the assessor you choose issues the report, because that independence is the entire point of it.
Know where you stand
A readiness engagement against the framework you have picked, run by your Lorikeet team and tracked in Talon. Not a gap-analysis PDF that ages out in a month.
- Define the boundary and the controls actually in scope
- Assess each one against where you stand, not what the policy claims
- Build the evidence set and name the owner who maintains it
- Work the gap list down until the write-ups are closed, not deferred
Produce the evidence
Penetration testing that satisfies the requirement, scoped to your boundary. Findings arrive mapped to the controls they break, so nobody hand-translates a PDF into a control matrix.
- Web apps, APIs, networks, cloud, mobile and source repositories
- Every finding countersigned by a qualified human tester
- Retest evidence, which is the half auditors actually chase
- Run by our AI pentester, by hand, or a mix of the two
The 14 standards we can assess you against.
This list is generated from the same framework catalogue the readiness programme and the Talon GRC module run on, so nothing appears here that we cannot actually assess. Pick yours for what the engagement covers and who issues the final report.
SOC 2 Type II
Service Organization Control 2 - Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy.
ISO 27001:2022
International standard for Information Security Management Systems (ISMS) - Annex A controls.
PCI DSS v4.0
Payment Card Industry Data Security Standard v4.0 - requirements for organisations handling cardholder data.
ISO/IEC 42001:2023
AI Management System (AIMS) - Annex A controls for governing AI you build, provide, or use.
HIPAA Security Rule
HIPAA Security Rule (45 CFR Part 164 Subpart C) - administrative, physical, and technical safeguards for ePHI.
CMMC 2.0 Level 2
Cybersecurity Maturity Model Certification 2.0 Level 2 - NIST SP 800-171 practices for handling CUI.
GLBA Safeguards Rule
Gramm-Leach-Bliley Act Safeguards Rule (16 CFR 314) - information security programme for financial institutions.
CIS Controls v8.1
Center for Internet Security Critical Security Controls v8.1 - 18 prioritised safeguards by Implementation Group.
FedRAMP Moderate
Federal Risk and Authorization Management Program - NIST SP 800-53 Rev 5 Moderate baseline for cloud services sold to US federal agencies.
NIST CSF 2.0
NIST Cybersecurity Framework 2.0 - outcomes across the Govern, Identify, Protect, Detect, Respond and Recover functions.
HITRUST CSF v11
HITRUST CSF v11 - certifiable control framework harmonising HIPAA, ISO 27001, NIST and PCI DSS for healthcare and its vendors.
GDPR
EU General Data Protection Regulation (2016/679) - lawful basis, data subject rights, security of processing and breach notification.
NIS2 Directive
Directive (EU) 2022/2555 - risk-management measures and incident reporting for essential and important entities in the EU.
DORA
Regulation (EU) 2022/2554 on digital operational resilience for the EU financial sector - ICT risk, incident reporting, resilience testing and third-party risk.
What people ask before they start.
Usually, though rarely as a line item that names one. PCI DSS is the explicit case: Requirement 11.4 mandates testing at least annually and after significant change. SOC 2 and ISO 27001 instead require you to demonstrate that controls work (CC7.1, and Clause 9.1 with Annex A 8.8), and auditors consistently read that as expecting independent technical testing. In practice we have not seen a SOC 2 Type II or an ISO certification audit that did not want to see a recent test.
No, and you should be wary of anyone who says they can do both. SOC 2 reports are issued by an independent CPA firm; ISO 27001 certificates come from an accredited certification body. That independence is the entire value of the report. We prepare you for it, produce the testing evidence, and work alongside the firm you pick, or introduce you to one.
Early enough to fix what it finds. The constraint is never the testing, it is the remediation: assessors want to see findings triaged, closed and retested, not a fresh report full of open criticals. For an ISO 27001 Stage 2 we suggest two to three months out. For a SOC 2 Type II, test at the start of the observation period so the controls are already operating when the window opens.
Not for the testing. Frameworks overlap heavily at the technical layer, so one properly scoped engagement can produce evidence for several at once. Findings are mapped to each framework's controls in parallel, so the same report answers your SOC 2 Trust Service Criteria and your ISO 27001 Annex A mapping. The readiness work differs more, because the control sets and evidence expectations genuinely diverge.
They redirect here and to the matching readiness page. They framed each framework as its own testing product, which is not how any of this works and pushed people toward the wrong engagement. Penetration testing lives under Security Testing; what each framework needs from it lives on that framework's readiness page.
Start with where you actually stand.
Tell us the framework and the date you are working toward. We will tell you what the readiness engagement covers, what testing the framework needs from you, and what we would sequence first.
