One platform for every surface attackers touch.

Point NANOTESTING at your production web apps, REST + GraphQL APIs, and GitHub repos and it runs the technical-vulnerability and secure-development checks an ISO 27001 auditor expects to see exercised on a schedule. Each scan writes compliance_evidence rows that roll up to specific Annex A controls: weak TLS / missing HSTS to A.8.24 (cryptography), missing security headers / CSP to A.8.26 (application security requirements), dependency CVEs and outdated components to A.8.8 (technical vulnerabilities), gitleaks secrets and leaked credentials to A.8.2 (privileged access), and SAST plus dependency hygiene to A.8.25 (secure development life cycle). The per-scan snapshot is immutable, so during the audit window you can show "as of this dated scan, A.8.24 was satisfied with this evidence."

A SOC 2 Type II audit covers a window, not a moment, so it needs evidence that recurring controls operated the whole time. Schedule weekly or daily scans and NANOTESTING produces dated proof against the Common Criteria: authentication and public-exposure findings map to CC6.1 (logical access controls), MFA / session / auth-header weaknesses to CC6.6 (boundary protection), weak TLS / missing HSTS / mixed content to CC6.7 (restriction of data transmission), missing security headers and input-validation defects to CC6.8 (malicious-software prevention), dependency CVE / monitoring gaps to CC7.1 (detection of vulnerabilities), and dependency hygiene to CC8.1 (change management). Export the one-click SOC 2 evidence pack and hand only that pack to your auditor.

PCI DSS 4.0 wants externally-facing systems scanned regularly and configured securely. NANOTESTING's read-only baseline plus the verified-owner active checks exercise the requirements a network/web scan can speak to: TLS posture, weak ciphers, and protocol downgrade map toward Requirement 4 (protect cardholder data in transit), missing security headers and exposed surfaces toward Requirement 6 (develop and maintain secure systems), and the dependency / SAST / secrets findings toward 6.3's known-vulnerability handling. The /compliance dashboard carries a dedicated PCI DSS 4.0 tab with per-control finding tallies, and every control row drills through to the exact findings behind it, so a QSA can move from a requirement straight to the evidence. Export the scoped PCI DSS PDF / CSV / JSON evidence pack for the assessor.

DORA (the EU Digital Operational Resilience Act) requires financial entities to run regular ICT vulnerability assessments and threat-led testing of their digital operational resilience. NANOTESTING is not a "DORA compliance map" - DORA is not one of our seven formally-mapped frameworks and we will never claim a control matrix for it. What it does honestly support: continuous, scheduled scanning across your web, API, repo, cloud, and Kubernetes surfaces, immutable per-scan snapshots, KEV + EPSS prioritisation, and auditor-ready reports you can put in front of a regulator or third-party-risk reviewer as evidence that ICT vulnerability assessment is happening on a recurring basis. Treat it as the always-on baseline that feeds your DORA testing programme, not a substitute for the threat-led penetration testing DORA also expects.

The same findings roll up against four more frameworks without a second tool. NIST CSF 2.0 and CIS Controls v8 carry per-control tallies derived from the risk_signals join (vulnerability management, secure configuration, data protection in transit). The HIPAA Security Rule tab maps web + API + cloud findings to the technical safeguards - 164.312(e)(1) Transmission Security lights up from your TLS / HSTS evidence, for example - and every control row links straight to the underlying finding signatures. Each framework has its own scoped PDF / CSV / JSON evidence pack so you hand the HIPAA pack to the HIPAA auditor and nothing else.

Reply to a security questionnaire or a buyer's due-diligence request with a current NANOTESTING report - website, API, repo (dependency CVEs, leaked secrets, IaC misconfig), cloud, and mobile assessed together - instead of stale screenshots. Internally, triage findings by KEV + EPSS-weighted priority (not raw severity), assign owners through the per-finding discussion thread, mark a finding fixed, and click "Run retest": a new scan re-checks the signature and flips it to verified-fixed if it is gone. The README risk badge and rating.json endpoint let you gate CI or publish your grade, so the evidence stays live between audits.