Applications & cloud
Know your web, API, SaaS, mobile and desktop apps — and the cloud they run on — can stand up to a real attacker. Hands-on testing, never a rebranded scan.
Apps · APIs · Mobile · Cloud
Penetration testing
Whatever worries you most, we can test it.
Applications, networks, cloud, devices, people and premises — find your gaps across every surface that matters to you, with one in-house team accountable for all of it. And when a framework is behind the test, the same team gets you ready for the assessment.
16
ways to find your gaps
4
attack surfaces covered
0
subcontractors near your systems
portal.cyberlysecure.com/acme-health/coverage
Acme Health — Test coverage4 practices · 16 services · one team
In-houseWeb app
API
SaaS
Mobile
Client-side
External
Internal
Segment test
Wireless
Vuln. assessment
Cloud config
Hardware & IoT
AI & LLM
Social eng.
Physical
Red team
ApplicationsNetworkCloud & devicesPeople & premises
6 in scope · one team · one report
In-house testers 0 subcontracted
Every surface one team
Applications
Web application pentest
Find and prove the weaknesses in your web applications before attackers do.
What the test coversApplications
API & web services pentest
Keep the APIs that connect your products, partners and data from becoming the way in.
What the test coversApplications
SaaS application pentest
Confidence that one of your customers can never reach another customer’s data.
What the test coversApplications
Mobile application pentest
Keep your iOS and Android apps — and the services behind them — out of attackers’ hands.
What the test coversApplications
Client-side application pentest
Make sure your desktop apps, thick clients, browser extensions and agents don’t open a back door.
What the test coversNetwork
External network pentest
See everything you expose to the internet the way an attacker sees it.
What the test coversNetwork
Internal network pentest
Know what an attacker could reach once they’re inside your network.
What the test coversNetwork
Network segmentation test
Prove your sensitive environments are truly isolated.
What the test coversNetwork
Wireless network pentest
Keep Wi-Fi and wireless from becoming the way in, at every site you operate.
What the test coversNetwork
Vulnerability assessment
Know every weakness across your estate, confirmed by a person and ranked by the risk it really carries.
What the test coversCloud & devices
Cloud configuration review
Close the gaps attackers look for first across AWS, Azure, GCP and Microsoft 365.
What the test coversCloud & devices
Hardware & IoT pentest
Protect your connected devices, their firmware and the apps that control them.
What the test coversCloud & devices
AI & LLM security testing
Put AI features in front of your users without handing attackers a new way in.
What the test coversPeople & premises
Social engineering
Learn how your people respond to real-world deception — before a real attacker finds out.
What the test coversPeople & premises
Physical pentest
Find out whether your buildings and on-site controls really keep attackers out.
What the test coversPeople & premises
Red team engagement
See how your whole organization holds up against a determined attacker — across cyber, human and physical.
What the test covers Every way in
Three practices, one team in your corner.
Networks & wireless
Find out what an attacker could reach from the internet, from inside your network and over the air — at every site you operate.
External · Internal · Wireless
People, premises & red team
See how your people and buildings hold up — not just your systems — against social engineering, physical entry and a full red-team exercise.
Social · Physical · Red team
What you get
Results you can act on — and prove.
Clear reporting for everyone who needs it, from your board to the engineer fixing the issue.
Technical report
Every finding, the evidence behind it and clear guidance your engineers can act on.
Executive summary
Your risk explained in plain language for leadership and the board.
Attestation letter
Signed confirmation of testing to hand your auditors.
Readout call
A walkthrough with the people who tested your systems.
Retest
Confirmation your fixes worked, documented for whoever needs to see it.
Testing your framework calls for
Every framework, mapped to the testing it expects.
Pick the framework on your desk and see exactly which tests its assessors and your customers will expect — each one run by the same in-house team that gets you ready for the assessment.
25frameworks and programs
16tests and assessments
1in-house team for testing and readiness
SOC 2
Certifications & attestationsTesting it calls for5 tests
- Web application pentest
- SaaS application pentest
- API & web services pentest
- Cloud configuration review
- External network pentest
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.
ISO 27001
Certifications & attestationsTesting it calls for6 tests
- Vulnerability assessment
- External network pentest
- Web application pentest
- Cloud configuration review
- Internal network pentest
- Social engineering
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.
PCI DSS
Certifications & attestationsTesting it calls for8 tests
- External network pentest
- Internal network pentest
- Network segmentation test
- Web application pentest
- API & web services pentest
- Vulnerability assessment
- Wireless network pentest
- Client-side application pentest
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.
HITRUST
Certifications & attestationsTesting it calls for5 tests
- External network pentest
- Internal network pentest
- Web application pentest
- Cloud configuration review
- Social engineering
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.
SOC 1
Certifications & attestationsTesting 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.
ISO 42001
Certifications & attestationsTesting it calls for4 tests
- AI & LLM security testing
- API & web services pentest
- Web application pentest
- Cloud configuration review
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.
CSA STAR
Certifications & attestationsTesting it calls for5 tests
- SaaS application pentest
- API & web services pentest
- Cloud configuration review
- Network segmentation test
- Vulnerability assessment
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.
CMMC
Government & defenseTesting it calls for7 tests
- Vulnerability assessment
- Internal network pentest
- Network segmentation test
- Cloud configuration review
- External network pentest
- Social engineering
- Wireless network pentest
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.
NIST SP 800-171
Government & defenseTesting it calls for5 tests
- Vulnerability assessment
- Internal network pentest
- Network segmentation test
- External network pentest
- Cloud configuration review
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.
FedRAMP
Government & defenseTesting it calls for7 tests
- SaaS application pentest
- Web application pentest
- API & web services pentest
- External network pentest
- Cloud configuration review
- Social engineering
- Mobile application pentest
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.
GovRAMP & TX-RAMP
Government & defenseTesting it calls for6 tests
- SaaS application pentest
- Web application pentest
- API & web services pentest
- External network pentest
- Cloud configuration review
- Vulnerability assessment
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.
HIPAA
Regulations & frameworksTesting it calls for10 tests
- Internal network pentest
- External network pentest
- Web application pentest
- API & web services pentest
- Cloud configuration review
- Vulnerability assessment
- Social engineering
- Hardware & IoT pentest
- Wireless network pentest
- Client-side application pentest
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.
NIST CSF
Regulations & frameworksTesting it calls for7 tests
- Vulnerability assessment
- External network pentest
- Internal network pentest
- Web application pentest
- Cloud configuration review
- Red team engagement
- Social engineering
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.
Privacy: GDPR, CCPA & state laws
Regulations & frameworksTesting it calls for5 tests
- Web application pentest
- API & web services pentest
- Mobile application pentest
- Cloud configuration review
- Vulnerability assessment
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.
DORA
Selling abroadTesting it calls for5 tests
- Red team engagement
- SaaS application pentest
- API & web services pentest
- Cloud configuration review
- Vulnerability assessment
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.
Cyber Essentials
Selling abroadTesting 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.
IRAP
Selling abroadTesting 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.
Risk assessment
Risk & security programsTesting it calls for5 tests
- Vulnerability assessment
- External network pentest
- Internal network pentest
- Cloud configuration review
- Web application pentest
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.
Security program
Risk & security programsTesting 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.
Vendor & third-party risk
Risk & security programsTesting 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.
Incident response
Risk & security programsTesting 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.
Business continuity & DR
Risk & security programsTesting 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.
Zero Trust
Risk & security programsTesting it calls for5 tests
- Internal network pentest
- Network segmentation test
- Cloud configuration review
- Red team engagement
- Social engineering
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.
Security awareness
Risk & security programsTesting 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.
M&A due diligence
Risk & security programsTesting 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.