CyberlySecure
Book a call
Risk & readiness assessment

Walk into your assessment already knowing where you stand.

A customer wants your SOC 2 report. A contract now carries a CMMC clause. A regulator, an insurer or your board wants to see that risk is under control. Readiness is the work that gets you there: find the gaps, close them, and arrive at your assessor’s door prepared — with one team that also tests what you build.

Book a readiness call See every program
25
frameworks and programs
0
certificates we issue — we’re on your side
1
team for readiness and testing
Your organization — readiness viewEvery requirement, an owner and its evidence
Readiness
  • SCOPE
    Scope and system boundary
    Ready
  • RISK
    Risk assessment and register
    Ready
  • ACCESS
    Access reviews, with evidence
    Gap · owner set
  • CHANGE
    Change management
    Closing
  • VENDOR
    Vendor management
    Gap · owner set
  • TEST
    Penetration test evidence
    Report in hand
Handed to the assessor you choose — the opinion is theirs
Gaps found before the audit
Readiness vs certification

The firm that prepares you can’t be the firm that certifies you.

Independence rules keep the two jobs apart. Certification bodies, CPA firms, QSAs, C3PAOs and 3PAOs exist to give an impartial opinion, and they are not allowed to build the controls they then judge. That leaves you with a gap before the assessment — and that gap is where we work.

Readiness — with usOn your side of the table
  • Scope the assessment and the systems it touches
  • Measure your controls against the framework, gap by gap
  • Write the policies, procedures and plans you’re missing
  • Assess and rank your risks in terms the business understands
  • Organize the evidence your assessor will ask for
  • Test what you build, so the controls hold up under attack
  • Stay beside you through remediation and the assessor’s questions
Formal opinion — your assessorIndependent, authorized, chosen by you
  • Holds the authorization the framework requires
  • Tests your controls independently
  • Forms the formal opinion
  • Issues the report, certificate or authorization package
  • Returns for surveillance, renewal or the next period

We prepare you; an authorized assessor you choose certifies, attests or authorizes. We never issue the certificate or report ourselves, so we are always on your side of the table.

Every program

Whatever framework is on your desk, start here.

Certifications and attestations, government and defense programs, regulations with no certificate at all, the frameworks you meet when you sell abroad — and the risk and security programs underneath every one of them.

Certifications & attestations

The reports and certificates your customers ask for by name, issued by the CPA firm or certification body you choose.

7 programs

SOC 2

Assessor-issued

Get ready for the SOC 2 Type I or Type II report your customers keep asking for, before the CPA firm you choose begins its examination.

ISO 27001

Assessor-issued

Build an information security management system that stands up in the certification audit: scope, risk treatment, Statement of Applicability and evidence for the Annex A controls.

PCI DSS

Assessor-issued

Scope, reduce and prepare your cardholder data environment for PCI DSS v4.0.1, whether you complete an SAQ or face a QSA.

HITRUST

Assessor-issued

Choose the right HITRUST assessment and get your environment, policies and evidence ready for e1, i1 or r2 validation.

SOC 1

Assessor-issued

Prepare the controls your customers’ financial auditors rely on for a SOC 1 Type I or Type II report.

ISO 42001

Assessor-issued

Put a certifiable AI management system around the models and AI features you build, buy or deploy.

CSA STAR

Assessor-issued

Publish accurate, defensible cloud security answers in the STAR Registry and prepare for STAR Certification or STAR Attestation.

Government & defense

Federal, defense, state and local programs that decide whether you can bid, win and keep public-sector work.

4 programs

CMMC

Assessor-issued

Get ready for a CMMC Level 1, 2 or 3 assessment: the right level, a defensible scope, an SSP that matches reality and evidence an assessor can verify.

NIST SP 800-171

No certificate

Protect CUI the way DFARS 252.204-7012 requires, with an SSP, a POA&M and an SPRS score that hold up when someone checks.

FedRAMP

Assessor-issued

Prepare your cloud service for a 3PAO assessment and agency authorization: the right baseline, a defensible boundary, the SSP package and controls that hold up.

GovRAMP & TX-RAMP

Assessor-issued

Sell your cloud service to state agencies, cities, counties and Texas public entities with a verified security posture they’ll accept.

Regulations & frameworks

Obligations with no certificate at all, where the proof is a program you can show a regulator, a partner or your board.

3 programs

HIPAA

No certificate

Get your Security Rule risk analysis, safeguards and business associate obligations in order before a customer, a breach or OCR asks.

NIST CSF

No certificate

Measure your program against CSF 2.0’s six functions and leave with a current profile, a target profile and a roadmap your board can follow.

Privacy: GDPR, CCPA & state laws

No certificate

Know what personal data you hold, why, and where it goes — and meet GDPR, CCPA/CPRA and the US state privacy laws with a program you can show.

Selling abroad

The frameworks a US company meets when its customers are in the EU, the UK or Australia.

3 programs

DORA

No certificate

Meet the ICT third-party terms your EU bank, insurer and fintech customers now flow down under DORA.

Cyber Essentials

Assessor-issued

Get your scope and five technical controls right before a UK certification body reviews them.

IRAP

Assessor-issued

Prepare your cloud service for an IRAP assessment against Australia’s Information Security Manual.

Risk & security programs

The risk assessment, plans and programs underneath every framework, and the ones your board and insurer ask about directly.

8 programs

Risk assessment

No certificate

One defensible, enterprise-wide view of your information-security risk: a register, a treatment plan and reporting your board can act on.

Security program

No certificate

Policies, governance, a roadmap and board reporting: the security program your customers, auditors and leadership assume you already have.

Vendor & third-party risk

No certificate

A third-party risk program that knows your vendors, tiers them by risk and keeps the evidence your auditors, examiners and customers ask to see.

Incident response

No certificate

An incident response plan, attack-specific playbooks and tabletop exercises your leaders and responders have actually rehearsed.

Business continuity & DR

No certificate

A business impact analysis, agreed recovery objectives, and continuity and DR plans you have exercised, so an outage or ransomware doesn’t become a shutdown.

Zero Trust

No certificate

Where you really stand against NIST SP 800-207 and the CISA Zero Trust Maturity Model, and a realistic roadmap to the architecture you want.

Security awareness

No certificate

Role-based training, phishing simulation and fraud-resistant procedures that change how your people behave, with metrics that prove it.

M&A due diligence

No certificate

Cyber risk in a target, framed for the deal team — price, reps and warranties, conditions and the post-close plan — plus sell-side readiness for companies being sold.

Where testing fits

Every framework, mapped to the testing it expects.

Many frameworks call for penetration testing outright, and most assessors and enterprise customers expect it. Pick yours and see the tests it calls for — run by the same team that gets you ready.

25frameworks and programs
16tests and assessments
1in-house team for testing and readiness
01

SOC 2

Certifications & attestations
Testing it calls for5 tests
One in-house team for testing and readiness

Testing evidence that the controls in your system description hold where customers — and attackers — actually connect.

Why these tests
  • Web application pentest Auditors evaluating monitoring (CC4.1) and system operations (CC7.1) commonly look for independent security testing of the application in scope, and enterprise buyers usually ask for a recent pentest summary alongside the SOC 2 report.
  • SaaS application pentest For multi-tenant platforms, customers want proof that one tenant can’t reach another tenant’s data — the question behind most Confidentiality commitments.
  • API & web services pentest APIs are often the real edge of the system in a SOC 2 description; testing them shows the logical access controls in CC6 hold where customers and integrations connect.
  • Cloud configuration review Most SOC 2 systems run in a public cloud; a configuration review shows the access, logging and encryption controls in your description are actually set the way you say.
  • External network pentest Shows your internet-facing perimeter matches the protections your system description claims.
SOC 2 readiness
02

ISO 27001

Certifications & attestations
Testing it calls for6 tests
One in-house team for testing and readiness

Technical evidence behind your Annex A controls, ready for the certification body’s auditors to examine.

Why these tests
  • Vulnerability assessment Annex A control 8.8 asks you to identify technical vulnerabilities, evaluate your exposure and act on it; regular, recorded scanning is the most direct evidence.
  • External network pentest An independent test of your internet-facing perimeter gives the certification body evidence that your network security and vulnerability controls work as your SoA states.
  • Web application pentest Control 8.29 calls for security testing in development and acceptance; an independent application test is how many organizations evidence it for customer-facing systems.
  • Cloud configuration review The 2022 control on information security for use of cloud services expects deliberate management of cloud security; a configuration review shows where your setup departs from your own policy.
  • Internal network pentest Network security, security of network services and segregation of networks (controls 8.20 to 8.22) are easier to defend in audit when an internal test has checked them.
  • Social engineering Awareness controls in the people theme carry more weight when you can show how staff respond to phishing, not only that training was delivered.
ISO 27001 readiness
03

PCI DSS

Certifications & attestations
Testing it calls for8 tests
One in-house team for testing and readiness

The Requirement 11 testing your QSA or SAQ asks for, with the cardholder data environment’s boundary proven, not assumed.

Why these tests
  • External network pentest Requirement 11.4.3 calls for external penetration testing at least annually and after any significant infrastructure or application upgrade or change.
  • Internal network pentest Requirement 11.4.2 calls for internal penetration testing on the same basis, covering the cardholder data environment perimeter and critical systems.
  • Network segmentation test If segmentation reduces your scope, Requirements 11.4.5 and 11.4.6 call for testing that it works — at least annually for merchants, and more often for service providers.
  • Web application pentest Requirement 11.4.1 defines penetration testing to include the application layer, and e-commerce checkouts and payment applications are exactly where attackers aim.
  • API & web services pentest Payment APIs and integrations with gateways and processors are part of the application layer an assessor expects to see tested.
  • Vulnerability assessment Requirement 11.3.1 calls for internal vulnerability scans on the schedule the standard sets. External scans under 11.3.2 must come from an Approved Scanning Vendor, which CyberlySecure is not.
  • Wireless network pentest Requirement 11.2 calls for finding and identifying every wireless access point, authorized or not, and wireless that touches the cardholder data environment has its own configuration rules; a wireless test shows whether a rogue or weak network gives a way in.
  • Client-side application pentest Payment and point-of-sale software running on workstations sits inside the cardholder data environment; testing the client application shows whether card data or keys can be pulled from the device itself.
PCI DSS readiness
04

HITRUST

Certifications & attestations
Testing it calls for5 tests
One in-house team for testing and readiness

Testing evidence for the requirement statements your External Assessor looks for across systems that hold health information.

Why these tests
  • External network pentest The HITRUST CSF includes requirement statements on technical vulnerability management and penetration testing, and External Assessors look for testing of internet-facing systems that handle protected health information.
  • Internal network pentest Internal testing gives evidence that controls on the in-scope network hold against an attacker who is already inside.
  • Web application pentest Patient portals and clinical applications are often the in-scope systems customers care most about, and application testing supports the related requirement statements.
  • Cloud configuration review Shows the controls you claim in cloud environments, including the ones you inherit, are configured as described.
  • Social engineering Phishing exercises support the security awareness requirement statements and show that training actually changes behavior.
HITRUST readiness
05

SOC 1

Certifications & attestations
Testing it calls for3 tests
One in-house team for testing and readiness

Testing evidence that the systems behind your clients’ financial reporting are as well protected as your control descriptions say.

Why these tests
  • Vulnerability assessment SOC 1 doesn’t require security testing, but access-related control objectives are stronger when you can show vulnerabilities on in-scope systems are found and fixed.
  • Web application pentest When customers reach the financial application through the web, testing it supports the objective that access is restricted to authorized users.
  • Cloud configuration review For platforms hosted in a public cloud, it shows the access and change controls over the in-scope environment are configured as described.
SOC 1 readiness
06

ISO 42001

Certifications & attestations
Testing it calls for4 tests
One in-house team for testing and readiness

Adversarial testing of the AI systems your management system covers, so your AI risk assessment rests on evidence.

Why these tests
  • AI & LLM security testing Verification and validation in the AI lifecycle, and AI risks such as prompt injection, sensitive data disclosure and insecure output handling, are best evidenced by testing the system adversarially.
  • API & web services pentest Most AI features are reached through APIs; testing them shows that model endpoints enforce authorization and do not expose one customer’s data to another.
  • Web application pentest The application wrapped around your model is part of the AI system, and its weaknesses are AI-system risks your impact and risk assessments should account for.
  • Cloud configuration review Training data, model artifacts and inference infrastructure usually live in cloud services; a configuration review checks that access to them matches your data-for-AI controls.
ISO 42001 readiness
07

CSA STAR

Certifications & attestations
Testing it calls for5 tests
One in-house team for testing and readiness

Proof that the answers in your CAIQ hold up when someone actually tests the cloud service behind them.

Why these tests
  • SaaS application pentest Application and interface security controls, and cross-tenant data access in particular, are what buyers reading your STAR entry most want to see evidenced.
  • API & web services pentest The CCM expects APIs to be designed, tested and protected to the same standard as the application; an API test evidences those controls directly.
  • Cloud configuration review The CCM’s infrastructure, identity, encryption and logging domains map closely to the configuration of the cloud accounts your service runs in.
  • Network segmentation test Infrastructure and virtualization security controls call for segmentation between tenants and environments; testing shows the isolation holds.
  • Vulnerability assessment Threat and vulnerability management controls expect regular detection and remediation of vulnerabilities, with records an auditor can sample.
CSA STAR readiness
08

CMMC

Government & defense
Testing it calls for7 tests
One in-house team for testing and readiness

Evidence that the boundary around your CUI holds — found by your side before a C3PAO looks.

Why these tests
  • Vulnerability assessment Requirement RA.L2-3.11.2 calls for periodic vulnerability scanning and scanning when new vulnerabilities are identified, and RA.L2-3.11.3 for remediating them according to risk; assessors ask for the scan results and the remediation trail.
  • Internal network pentest An internal test shows whether a compromised workstation can reach CUI, which is direct evidence for access control and boundary requirements. Level 3 adds a penetration testing requirement from NIST SP 800-172 (CA.L3-3.12.1e).
  • Network segmentation test If an enclave is what keeps the rest of your network out of scope, a segmentation test proves the boundary holds — support for SC.L2-3.13.1 and for the scoping argument itself.
  • Cloud configuration review Government cloud tenants are where CUI often lives. A configuration review checks them against the requirements you claim and the responsibilities you inherit from the provider.
  • External network pentest Internet-facing systems are the front door to the CUI environment; testing them gives you boundary protection evidence and real findings to fix before an assessor looks.
  • Social engineering Security awareness training is a Level 2 requirement, and Level 3 adds training focused on social engineering and advanced threats; a phishing exercise shows whether that training changes behavior.
  • Wireless network pentest Level 2 requires you to authorize wireless access and protect it with authentication and encryption (AC.L2-3.1.16 and 3.1.17); a wireless test shows whether those controls hold in practice.
CMMC readiness
09

NIST SP 800-171

Government & defense
Testing it calls for5 tests
One in-house team for testing and readiness

Testing that turns your SSP and SPRS score from claims into evidence a prime contractor can rely on.

Why these tests
  • Vulnerability assessment Requirement 3.11.2 calls for scanning for vulnerabilities periodically and when new ones are identified, and 3.11.3 for remediating them according to risk.
  • Internal network pentest Requirement 3.12.1 asks you to periodically assess whether your controls are effective. An internal test answers that directly for access control and least privilege around CUI.
  • Network segmentation test Requirements 3.13.1 and 3.13.5 cover boundary protection and separating publicly accessible components; a segmentation test proves the CUI boundary you drew actually holds.
  • External network pentest Your internet-facing systems are where attackers start. Testing them gives you boundary protection evidence and findings to close before they become incidents you have to report.
  • Cloud configuration review When CUI lives in a cloud tenant, the provider’s authorization covers its side only. A configuration review checks the settings you control against the requirements you claim.
NIST SP 800-171 readiness
10

FedRAMP

Government & defense
Testing it calls for7 tests
One in-house team for testing and readiness

The ground a 3PAO will cover, covered first by people on your side, so the assessment holds fewer surprises.

Why these tests
  • SaaS application pentest Control CA-8 requires penetration testing at Moderate and High, and FedRAMP’s penetration test guidance includes tenant-to-tenant and tenant-to-management attack vectors. Testing early shows what a 3PAO’s test is likely to find.
  • Web application pentest The customer-facing application is usually the largest part of the attack surface inside the boundary, and the place agency reviewers look hardest.
  • API & web services pentest APIs that agencies integrate with cross the boundary by design; testing them checks authentication, authorization and tenant isolation where federal data moves.
  • External network pentest FedRAMP’s guidance includes an attack vector from outside the system to the CSP target system; an external test covers the same ground before the 3PAO does.
  • Cloud configuration review Most FedRAMP services run on an authorized IaaS. A configuration review checks the settings you own against the baseline controls you claim to meet.
  • Social engineering The guidance also includes an external-to-corporate vector, which reaches the people who administer your service; a phishing exercise measures that exposure.
  • Mobile application pentest If your service offers a mobile app, the guidance includes a mobile-application-to-CSP vector that an assessor will expect to see addressed.
FedRAMP readiness
11

GovRAMP & TX-RAMP

Government & defense
Testing it calls for6 tests
One in-house team for testing and readiness

Testing evidence state, local and Texas agency buyers can rely on, from a team based in Houston.

Why these tests
  • SaaS application pentest NIST SP 800-53 control CA-8 calls for penetration testing at the higher baselines, and state buyers routinely ask for a recent test of the service itself, including tenant isolation.
  • Web application pentest Public-facing portals for residents and staff are the most exposed part of most state cloud services and the first thing a 3PAO or agency reviewer probes.
  • API & web services pentest Integrations with state systems move sensitive data through APIs; testing them checks authentication and authorization where that data crosses the boundary.
  • External network pentest Your internet-facing infrastructure is in scope for every baseline; an external test produces boundary protection evidence and findings to close before assessment.
  • Cloud configuration review Most state cloud services run on a public cloud platform, and a configuration review checks the settings you own against the controls you claim.
  • Vulnerability assessment Control RA-5 requires vulnerability scanning, and continuous monitoring depends on scan results that cover the whole inventory and feed the POA&M.
GovRAMP & TX-RAMP readiness
12

HIPAA

Regulations & frameworks
Testing it calls for10 tests
One in-house team for testing and readiness

Evidence for your Security Rule risk analysis that shows how close an attacker could really get to ePHI.

Why these tests
  • Internal network pentest The risk analysis must cover vulnerabilities, not just policies; an internal test shows how far an attacker on your network could get toward systems holding ePHI.
  • External network pentest Internet-facing VPNs, remote access, email and portals are where many healthcare intrusions begin, and the proposed Security Rule update would make penetration testing an explicit expectation.
  • Web application pentest Patient portals, provider dashboards and scheduling apps put ePHI one broken access check away from the wrong person.
  • API & web services pentest FHIR and HL7 interfaces, EHR and payer integrations, and partner APIs move PHI between systems and need authorization tested record by record.
  • Cloud configuration review Where ePHI lives in AWS, Azure or Google Cloud, misconfigured storage, identity and logging are among the most common causes of exposure.
  • Vulnerability assessment Regular scanning feeds the risk analysis and the evaluation standard, and is one of the measures the proposed Security Rule update names explicitly.
  • Social engineering Phishing is a leading route into healthcare networks; testing your workforce shows whether the security awareness and training safeguard is working.
  • Hardware & IoT pentest Connected medical and building devices often share networks with ePHI and can’t be patched like ordinary IT, so they belong in the risk analysis with real evidence.
  • Wireless network pentest Clinical, staff and guest Wi-Fi often run beside systems that hold ePHI; a wireless test shows whether the technical safeguards you rely on actually keep them apart.
  • Client-side application pentest Desktop clinical and billing applications often store or cache ePHI on the endpoint; testing them shows whether access control and encryption hold where the data actually sits.
HIPAA readiness
13

NIST CSF

Regulations & frameworks
Testing it calls for7 tests
One in-house team for testing and readiness

Shows whether the outcomes in your current profile stand up to a real attacker, not only on paper.

Why these tests
  • Vulnerability assessment The Identify function expects vulnerabilities in assets to be identified, validated and recorded; regular scanning is the baseline evidence.
  • External network pentest Shows whether the outcomes you score under Protect hold up against your internet-facing attack surface.
  • Internal network pentest Tests identity, access control and segmentation outcomes from the inside, where profiles are often scored more generously than reality.
  • Web application pentest Platform and data security outcomes for the applications that hold your customers’ data are only proven by testing them.
  • Cloud configuration review Measures platform and data security outcomes in the cloud services that now carry most workloads.
  • Red team engagement Exercises Detect, Respond and Recover together, and CSF 2.0 expects improvements to be identified from security tests and exercises.
  • Social engineering Gives real evidence for awareness and training outcomes beyond course-completion records.
NIST CSF readiness
14

Privacy: GDPR, CCPA & state laws

Regulations & frameworks
Testing it calls for5 tests
One in-house team for testing and readiness

Testing that shows the personal data you have mapped is as protected as your notices and contracts promise.

Why these tests
  • Web application pentest GDPR Article 32 and the CCPA’s reasonable-security duty both depend on applications that don’t leak personal data through broken access control.
  • API & web services pentest APIs carry personal data to partners and apps, and an authorization flaw there can expose records in bulk.
  • Mobile application pentest Mobile apps collect location, device identifiers and sensitive data, and embed third-party SDKs that may share it in ways your notice doesn’t disclose.
  • Cloud configuration review Misconfigured cloud storage and identity are among the most common causes of personal data breaches.
  • Vulnerability assessment Regular scanning is basic evidence of the security of processing the laws require, and it feeds the CCPA cybersecurity audit.
Privacy: GDPR, CCPA & state laws readiness
15

DORA

Selling abroad
Testing it calls for5 tests
One in-house team for testing and readiness

Resilience testing your EU financial customers can rely on when DORA’s expectations reach their ICT providers.

Why these tests
  • Red team engagement DORA requires significant financial entities to run threat-led penetration testing under the TIBER-EU-based RTS, and you may be asked to take part. A red-team engagement outside that regime is how you learn how your detection and response hold up beforehand.
  • SaaS application pentest Article 25 lists penetration testing among the tests a financial entity’s resilience program covers, and customers relying on your platform for an important function will ask to see recent results.
  • API & web services pentest EU financial customers usually integrate through your APIs, so authorization, data exposure and abuse of those interfaces are what their vendor-risk teams ask about first.
  • Cloud configuration review Data location, segregation, backup and recovery commitments in a DORA contract depend on how your cloud estate is actually configured.
  • Vulnerability assessment Vulnerability assessments and scans are the first item in DORA’s Article 25 list of resilience tests, and customers expect recurring evidence of them.
DORA readiness
16

Cyber Essentials

Selling abroad
Testing it calls for3 tests
One in-house team for testing and readiness

A check of the five technical controls, looked at the way a certification body will look at them.

Why these tests
  • Vulnerability assessment Cyber Essentials Plus includes vulnerability scanning of your internet-facing systems and sampled devices, so a scan of your own first shows missing updates and weak configurations before the certification body does.
  • External network pentest The firewall control turns on what is exposed at your boundary. Testing your external footprint finds open administrative interfaces and forgotten services that would fail that requirement.
  • Cloud configuration review Cloud services are in scope, and multi-factor authentication, administrator separation and secure configuration there are frequent reasons for failure.
Cyber Essentials readiness
17

IRAP

Selling abroad
Testing it calls for4 tests
One in-house team for testing and readiness

Technical evidence against the ISM controls an IRAP assessor and your government buyer will weigh.

Why these tests
  • Cloud configuration review IRAP assessments of cloud services examine how your tenancy is configured, including identity, network controls, encryption and logging, so a configuration review shows where the ISM will not be met.
  • SaaS application pentest Agencies weighing your report want confidence that the service itself resists attack, and the ISM’s software development guidelines expect applications to be security tested.
  • External network pentest Your internet-facing gateways and administrative interfaces are among the first things an assessor and an agency’s security team consider.
  • Vulnerability assessment The ISM expects ongoing vulnerability scanning and patching, and the Essential Eight patching strategies depend on knowing what is unpatched.
IRAP readiness
18

Risk assessment

Risk & security programs
Testing it calls for5 tests
One in-house team for testing and readiness

Real findings behind your likelihood ratings, so your risk register reflects what an attacker could actually do.

Why these tests
  • Vulnerability assessment Feeds the risk assessment real vulnerability data across your estate instead of assumed weaknesses, supporting the vulnerability identification that NIST SP 800-30 and the NIST SP 800-171 risk assessment family call for.
  • External network pentest Shows what an outside attacker can actually reach and exploit, which is the evidence behind the likelihood ratings for your internet-facing risks.
  • Internal network pentest Shows how far an attacker or a compromised account can move once inside, informing impact ratings and the real value of segmentation and identity controls.
  • Cloud configuration review Examines the cloud accounts where much of your sensitive data now lives, so misconfiguration risk is measured rather than guessed.
  • Web application pentest Validates the risks in the applications that hold customer data and gives auditors independent evidence that the related controls work.
Risk assessment readiness
19

Security program

Risk & security programs
Testing it calls for4 tests
One in-house team for testing and readiness

An independent measure of whether your program’s controls work, in terms your board and insurer recognize.

Why these tests
  • Vulnerability assessment Provides the baseline data for your vulnerability management standard and the metrics that show whether it is working.
  • External network pentest Gives the program an independent measure of internet-facing exposure, one of the first things customers and insurers ask about.
  • Web application pentest Tests the applications your customers depend on and backs your secure development policy with real evidence.
  • Social engineering Measures how well awareness training and identity verification procedures hold up against realistic phishing and pretexting.
Security program readiness
20

Vendor & third-party risk

Risk & security programs
Testing it calls for3 tests
One in-house team for testing and readiness

Independent testing evidence for the due diligence your own customers run on you.

Why these tests
  • SaaS application pentest Gives your customers’ third-party risk teams the independent test evidence and summary letter they ask for when they review you as a vendor.
  • API & web services pentest Tests the API integrations that connect vendors to your systems, where third-party access often reaches further than anyone intended.
  • External network pentest Shows customers and auditors that your internet-facing exposure has been independently tested, a standard request in vendor due diligence.
Vendor & third-party risk readiness
21

Incident response

Risk & security programs
Testing it calls for2 tests
One in-house team for testing and readiness

Realistic attacks that put your plan, your playbooks and your responders under genuine pressure.

Why these tests
  • Red team engagement A red team engagement tests whether your detection and response hold up against a realistic adversary — the live counterpart to a tabletop, and evidence that the plan works outside the conference room.
  • Social engineering Phishing and pretexting campaigns test the front door most incidents come through, and show whether staff report suspicious messages to the people your plan says should receive them.
Incident response readiness
22

Business continuity & DR

Risk & security programs
Testing it calls for3 tests
One in-house team for testing and readiness

Shows whether recovery would really work when an attacker, not a power cut, is the reason you need it.

Why these tests
  • Cloud configuration review A cloud configuration review checks backup vaults, immutability and object-lock settings, cross-account isolation and the permissions that could let an attacker delete your recovery copies.
  • Internal network pentest An internal penetration test shows whether an attacker who lands on a workstation can reach backup servers, hypervisors and domain controllers — the systems your recovery depends on.
  • Red team engagement A red team engagement can make your backup and recovery infrastructure an objective, testing whether your detection notices an attacker going after your ability to recover.
Business continuity & DR readiness
23

Zero Trust

Risk & security programs
Testing it calls for5 tests
One in-house team for testing and readiness

Proof of whether a foothold can still move freely, measured against the architecture you are building toward.

Why these tests
  • Internal network pentest Shows how far an attacker can move laterally today, the clearest measure of how much implicit trust remains inside your network.
  • Network segmentation test Verifies that the segmentation and micro-segmentation in your target architecture actually block the traffic they are meant to block.
  • Cloud configuration review Checks identity policies, network controls and workload trust in your cloud accounts against the least-privilege model Zero Trust depends on.
  • Red team engagement Tests the architecture as a whole against a goal-driven adversary, including identity attacks designed to slip past individual controls.
  • Social engineering Puts phishing-resistant MFA, help-desk identity verification and user reporting to the test against the attacks they exist to stop.
Zero Trust readiness
24

Security awareness

Risk & security programs
Testing it calls for2 tests
One in-house team for testing and readiness

Shows how your people respond to a convincing lure or a stranger at the door, so training targets real behavior.

Why these tests
  • Social engineering Phishing, vishing and pretexting campaigns run by an independent tester show how your people respond to realistic lures and give your awareness program a baseline to measure progress against.
  • Physical pentest Physical testing checks whether staff challenge tailgaters, verify visitors and protect their badges — behaviors awareness training teaches but rarely measures.
Security awareness readiness
25

M&A due diligence

Risk & security programs
Testing it calls for4 tests
One in-house team for testing and readiness

Evidence of what a target actually exposes, framed so the deal team can price it.

Why these tests
  • External network pentest With the target’s written authorization, an external penetration test shows whether its internet-facing exposure is actually exploitable — evidence that turns a concern into a finding the deal can price.
  • Vulnerability assessment A vulnerability assessment across the target’s external or internal estate gives a broad read on patching and technical debt, before or after closing.
  • Web application pentest For software and SaaS targets, testing the product itself shows whether the asset you are paying for carries security flaws your new customers will eventually find.
  • Cloud configuration review A cloud configuration review at or after closing shows how the target’s cloud accounts are really set up — identity, logging, exposure and backups — before you connect them to yours.
M&A due diligence readiness
Every penetration test and assessment
What you receive

Something you can hand your assessor, your board and your customer.

Every program page lists exactly what you get for that framework. Across all of them, readiness leaves you with this.

Gap assessment

Every requirement in scope, where you stand against it and what closing it takes — ranked so you fix what an assessor would flag first.

Risk assessment and register

Your real risks, rated for likelihood and impact, with owners and a treatment decision for each.

Policies and procedures

Written for how your organization actually works, so your people can follow them and your assessor can test them.

Remediation roadmap

The gaps turned into a sequenced plan with owners, so progress is visible to your team and your leadership.

Evidence map

Which artifact proves which control, where it lives and who maintains it — the binder your assessor expects.

Leadership briefing

Where you stand and what it will take, in plain terms for your board, investors or the customer waiting on you.

Testing, where it’s called for

The penetration tests and vulnerability assessments your framework expects, from the same in-house team.

Assessor handoff

Your scope, your system description and your evidence, organized for the assessor you choose.

Do you issue SOC 2 reports, ISO certificates or CMMC certifications?

No. Those come from authorized assessors — licensed CPA firms, accredited certification bodies, C3PAOs, 3PAOs, QSAs and the like. We do the readiness work before that assessment, and you choose the assessor. Keeping the two apart is exactly what independence rules require.

Why not hire the assessor to do the readiness work too?

In most frameworks they can’t, or can only do a little of it. An assessor that designed your controls would be judging its own work. A readiness partner can roll up its sleeves: write the policy, fix the configuration, rehearse the interview. The assessor then gets a prepared organization, and you get a cleaner assessment.

What does readiness actually leave us with?

A clear gap assessment, a risk register, the policies and procedures you were missing, a remediation roadmap, an evidence map and a leadership briefing — plus the penetration testing your framework expects, if it expects any. Each program page lists exactly what you receive for that framework.

We have more than one framework on the horizon. Do we start over for each?

No. SOC 2, ISO 27001, HIPAA, NIST CSF, CMMC and the rest overlap heavily. We map your controls once and show where one piece of evidence answers several frameworks, so the second program costs far less than the first.

Can you help if the assessor has already found problems?

Yes. Bring the findings, the exceptions or the plan of action. We help you understand what the assessor needs to see, close the gaps and organize the evidence for their next visit.

Is readiness only for certifications?

No. Plenty of obligations come with no certificate at all — HIPAA, privacy laws, DORA, NIST CSF, an insurer’s questionnaire, a board that wants to know where the risk is. Readiness for those is the program itself: the risk assessment, the policies, the plans and the proof that they work.

Where does penetration testing fit?

Many frameworks call for it outright, and most assessors and enterprise customers expect it. Because testing is our other core service, the readiness team and the testers are the same company — your gaps get found by people who know what the assessor will look for.

Readiness and testing, one team

Tell us which framework is on your desk.

One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you. The same team runs the penetration tests your framework expects.

Book a readiness call See penetration testing
Risk & readiness assessment25 frameworks and programsPenetration testing16 tests and assessments
Free attack-surface snapshot

Give us a domain. See what an attacker sees.

Not sure where to start? One of our testers reviews your internet-facing footprint and sends you a short summary of what an attacker would see — free. Nothing you don’t own is ever touched, and there’s no sales sequence.

  • Internet-facing hosts
  • Exposed services
  • Leaked credentials
  • TLS certificate hygiene
Download a sample report Review the full service list

Request your snapshot

Free. No obligation.

We only ever test assets you own, with your written authorization. How we handle your details