SOC 2 Type II — Trust Services Criteria
The AICPA's framework for evaluating the security, availability, processing integrity, confidentiality, and privacy controls of service organisations. Type II reports assess whether controls operate effectively over a defined audit period, typically six to twelve months.
See where NodeZero appliesWhat is SOC 2?
SOC 2 (System and Organization Controls 2) is a framework developed by the American Institute of Certified Public Accountants (AICPA) for evaluating the controls of service organisations. It is built on five Trust Services Criteria -- Security, Availability, Processing Integrity, Confidentiality, and Privacy -- with Security (the Common Criteria) being mandatory in every SOC 2 engagement. A Type II report assesses whether controls are not only designed appropriately but operate effectively over an audit period, typically six to twelve months.
SOC 2 has become the de facto trust standard for technology companies, SaaS providers, and managed service providers. Enterprise buyers routinely require SOC 2 Type II reports before signing contracts, and the report is often the first document requested during vendor security assessments. The Common Criteria cover control environment, risk assessment, monitoring, logical and physical access, system operations, and change management -- areas where penetration testing provides direct evidence of control effectiveness.
Where NodeZero applies
NodeZero provides direct evidence for the Security criterion -- the mandatory Common Criteria in every SOC 2 engagement. Penetration testing validates whether logical access controls actually prevent unauthorised access (CC6), whether system operations detect and respond to anomalies (CC7), and whether the control environment is effective against real attack techniques. For criteria covering governance (CC1), communication (CC2), risk assessment (CC3), monitoring processes (CC4), and change management (CC8), we map where organisational evidence is needed beyond what technical testing can demonstrate.
This mapping reflects our best-effort analysis of where NodeZero's autonomous pentesting produces relevant technical evidence against each requirement. It is intended to help you focus security effort on the controls NodeZero can test — not to serve as a compliance certification. You remain responsible for your own compliance assessment, for validating applicability to your environment, and for evidencing the requirements NodeZero does not directly test.
Please note the following require separate evidence: CC1 -- Control environment, CC2 -- Communication and information and CC8 -- Change management.
Showing coverage grouped by compliance category.
CC3 -- Risk assessment
Partial coverage. NodeZero identifies real, exploitable risks.
Internal pentestingCore
CC3.2 expects risk assessment grounded in reality — NodeZero surfaces the risks an attacker would actually exploit, not hypothetical CVSS scores.
High-Value TargetingElite only
Infers likely crown jewels and prioritises the attack paths that reach them, expressing exposure in business-impact terms (such as operational disruption or executive impersonation) the board understands — supporting, not evidencing, the change-risk assessment CC3.4 expects.
CC4 -- Monitoring activities
Direct coverage through deception, EDR measurement, and attacker-behaviour generation.
NodeZero TripwiresPro & Elite
CC4.1 expects ongoing evaluation — Tripwires plant decoys during a test so any interaction raises a high-fidelity alert to your SIEM, validating whether your monitoring actually detects an attacker in production.
Endpoint Security EffectivenessCore
Per-host and per-vendor EDR block/allow data mapped to MITRE ATT&CK — concrete evidence of whether monitoring controls are functioning.
Internal pentestingCore
Every NodeZero action is timestamped with proofs and commands — giving you a precise timeline to check whether your SIEM detected the deficiency and how quickly your team could have acted on it.
CC5 -- Control activities
Direct coverage. Tests whether control activities are effective under real attack.
Internal pentestingCore
CC5.1 expects evidence that control activities actually mitigate risk; proof-of-exploit output is the most direct form of that evidence.
Quick VerifyCore
Audit-ready re-test evidence — closes the loop between finding and remediation for the service audit.
CC6 -- Logical and physical access controls
Strongest alignment. NodeZero directly tests logical access control effectiveness.
AD Password AuditCore
It is not uncommon for NodeZero to crack more than 50% of the passwords it tests on a first audit — direct evidence of whether CC6.1 logical access controls are holding.
Web application pentestingPriced separately
Tests the audited application's own access model — authenticated, role-based workflows exercised for broken access control, IDOR and BOLA — proving whether one tenant or role can reach another's data. It evidences enforcement in the product; provisioning and deprovisioning processes remain organisational.
Phishing Impact TestingCore
Uses a phished credential to prove how far an attacker gets once it is captured — showing whether MFA and downstream access controls actually contained it, rather than assuming they did.
Internal pentestingCore
Proves end-to-end paths from initial access to domain compromise — evidence of whether CC6.3 least-privilege and segregation-of-duties boundaries hold.
BloodHound (integrated)Core
Makes the over-privileged relationships CC6.3 requires you to manage visible and auditable.
Cloud pentestingCore
SaaS-era CC6.6 scope is hybrid; cloud pentesting extends access-control validation across the boundary most service audits miss.
External pentestingCore
Where a public-facing service exposes an exploitable weak or unencrypted channel, external pentesting proves an attacker could reach it — evidence that the transmission protections CC6.7 relies on are not, in practice, closed.
Advanced Data PilferingElite only
Autonomously hunts and reaches sensitive data across shares, SYSVOL and cloud storage, then emulates stealthy exfiltration to test whether your defences would notice — proof of which data an attacker could actually move or remove, and whether the attempt would be detected, covering the data-removal half of CC6.7 that transmission-focused testing does not reach.
Endpoint Security EffectivenessCore
Runs real attack techniques — OS credential dumping, EDR evasion, and malicious post-exploitation via NodeZero RAT — against real hosts, then reports per-host, per-vendor block/allow outcomes mapped to MITRE ATT&CK: direct evidence of whether the anti-malware and EDR controls CC6.8 requires actually prevent or detect malicious software in production.
CC7 -- System operations
Direct coverage. Tests vulnerability detection, anomaly detection, and incident remediation.
Internal pentestingCore
Proof-of-exploit findings are the strongest evidence of whether your detection procedures actually surface new vulnerabilities.
Web application pentestingPriced separately
Adds an application-layer identification procedure — recurring autonomous tests of the entity's own applications that surface OWASP-class and business-logic vulnerabilities scanners cannot, in pre-production and production.
Rapid ResponsePro & Elite
Covers the newly-disclosed-exploit window between a CVE going public and your next periodic scan — the gap CC7.1 scanning misses.
NodeZero TripwiresPro & Elite
Fires a high-fidelity alert the instant an attacker touches a decoy — auditor-visible proof of whether your anomaly-detection layer sees the intrusion.
Quick VerifyCore
CC7.4 expects post-incident remediation; Quick Verify produces the audit-ready evidence the remediation actually worked.
CC9 -- Risk mitigation
Partial coverage. Validates whether risk-mitigation controls are effective in practice.
Internal pentestingCore
CC9.1 asks whether the mitigations you cite in your SOC 2 narrative actually work — NodeZero provides that evidence through working exploitation attempts.
Quick VerifyCore
Produces audit-ready evidence that each mitigation holds — closes the loop between finding and remediation for the service audit.
See every control mapped to NodeZero
The full control-by-control coverage map — every SOC 2requirement matched to the NodeZero capability that produces evidence for it, with maturity-level grouping and source citations. We'll email you the link and a downloadable copy.
Who does this apply to?
SOC 2 is not mandated by law, but it is effectively required by the market. Technology companies, SaaS providers, cloud service providers, managed service providers, data centre operators, and any organisation that processes, stores, or transmits customer data will encounter SOC 2 requirements in sales cycles and procurement processes. Enterprise customers, particularly in financial services, healthcare, and government, routinely require a current SOC 2 Type II report as a condition of doing business.
The report is issued by a CPA firm following an audit. Unlike certifications that are pass/fail, a SOC 2 report includes the auditor's opinion on the design and operating effectiveness of controls, a description of the system, and details of any exceptions identified during testing. Prospective customers and partners use these reports to assess your security posture without conducting their own audits.
If your organisation sells to enterprises, handles customer data, or operates infrastructure that other organisations depend on, you will likely need a SOC 2 Type II report. Australian and New Zealand organisations increasingly encounter SOC 2 requirements when selling to US-based customers or operating in global markets.
Close the gaps before your next assessment
See how NodeZero generates audit-ready evidence for your compliance obligations. We'll walk you through where NodeZero applies for your specific framework.