SOC 2 evidence the auditor actually accepts.

TL;DR — what this does for SOC 2

NSAuditor AI EE generates a pre-audit gap report with institutional-level evidence controls. It maps cloud and network scan findings to specific Trust Services Criteria, produces evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars), and ships in machine-readable form suitable for GRC platform ingestion (Vanta + Drata + Secureframe connectors shipped, opt-in early-access).

It is not a SOC 2 Type II evidence pack on its own (Type II requires recurring-scan attestation across 6–12 months — supported via recurring-scan attestation + SLA/MTTR tracking, both shipped). It is not a replacement for governance, risk-assessment, or business-continuity evidence. It is not a substitute for a CPA-firm audit — this is the pre-audit report you give your auditor so they don't bill you for finding what you already knew.

The market split: GRC platforms (Vanta, Drata, Secureframe) automate workflow but lack native vulnerability scanning; legacy scanners (Tenable, Qualys, Rapid7) produce voluminous CVE reports but don't map findings to TSC controls. Our wedge is the bridge — deep scanning + auditor-mapped output + opt-in GRC push.

Coverage matrix

Source of truth is data/compliance/soc2.json in the EE package; this matrix mirrors it. A test asserts the two stay in sync.

What "Covered" means here

"Covered" means the engine produces direct evidence the auditor can attach to the control. CC6.1 (Logical access security) catches password-only SSH, exposed admin panels, AWS users without MFA, shadow admins, privilege-escalation paths, Azure RBAC role assignments at subscription scope, and RDS IAM database authentication evidence (password-less auth on mysql/postgres/mariadb/aurora). CC6.6 (Network-boundary protection) flags exposed-to-Internet management ports, Azure NSG 0.0.0.0/0 rules, the 12-dimension air-gapped backup-vault attestation arc (plugin 1130) verifying cryptographic isolation of LogicallyAirGappedBackupVault resources across vault TYPE + ARN account-segment + KMS key-policy + KMS Grants + MRK-replica topology + source-account VPC-endpoint policy, the AWS SQS transit-encryption policy + SNS topic-policy permissive-Principal classifier with NotAction-Allow + NotPrincipal-Allow + Resource-scope filtering (plugin 1150), and the AWS EC2 SG Perimeter Auditor (plugin 1170) with deterministic CRITICAL findings on IPv4 0.0.0.0/0 and IPv6 ::/0 ingress to 13 RESTRICTED_PORTS (SSH/RDP/MS SQL/MySQL/Postgres/Redis/Memcached/MongoDB/Elasticsearch/CouchDB/Docker daemon/Kubelet API) — orthogonal evidence to plugin 1023 zero-trust-checker (1023 reads OBSERVED open ports; 1170 reads DECLARED SG policy). CC6.7 (Data in transit) flags TLS 1.0/1.1, weak ciphers, missing HSTS, API Gateway custom-domain TLS policy with worst-policy tracking (plugin 1050), and RDS parameter-group SSL enforcement (postgres rds.force_ssl + mysql require_secure_transport). CC7.1 is evidenced by CVE matching against an offline NVD feed, EOL-software detection, S3 access-logging gaps (raised only when no CloudTrail data-event trail already covers the bucket — coverage is judged per selector, and org trails or prefix-scoped selectors are refused rather than assumed), CloudTrail log-file-validation gaps, CodePipeline stale-execution detection + S3 cross-region replication destination-bucket reachability, and SQS dead-letter queue presence (plugin 1150 — dual-mapped with A1.2). CC7.2 + CC7.3 — covered via the CloudTrail Operational Integrity Auditor (1040). C1.1 (Confidentiality) is evidenced by S3 misconfiguration findings, Azure Storage, KMS wildcard-principal classification (plugin 1070), Lambda EOL runtime / environment-variable secret detection (1080), Secrets Manager + SSM Parameter Store metadata-only audit with the ZDE verb-prefix denylist (1090), SQS + SNS encryption-at-rest with KMS-custody classification (plugin 1150), and RDS storage encryption with the headline kms:DescribeKey cross-reference promoting UNVERIFIABLE :key/UUID ARN shapes to deterministic PASS (CUSTOMER-managed CMK) or MEDIUM (AWS-managed) — without compromising the conservative-classifier discipline (AccessDenied / NotFound / unknown KeyManager → still leaves at LOW). C1.2 (Disposal of confidential information) is evidenced by S3 lifecycle findings, CloudTrail trail-destination buckets, and the AWS Backup Auditor (1130) — the most-evidenced control across the backup substrate. The full list with example findings and TSC rationale (spanning AWS + Azure + GCP plugins, 29 EE plugins) lives in the EE package's SOC 2 coverage doc.

What "Partial" means

NSAuditor AI evidences one dimension of these controls (typically the configuration-state-at-this-moment dimension). CC6.3 is partial because we detect stale IAM keys but the removal-cadence dimension needs CTEM history. CC8.1 is partial because we capture configuration snapshots but change-authorization linkage requires ITSM/Git PR webhook integration. A1.2 is substantially evidenced: plugin 1130 AWS Backup Auditor closes the "Backup/recovery posture itself" gap across the full AWS Backup substrate (Plans, Vaults, Recovery Points, Selections, Frameworks, Restore Testing Plans, ReportPlans, Legal Holds, vault TYPE, Vault Tags, Vault Access Policy); plugin 1140 AWS RDS Auditor adds Multi-AZ deployment evidence, backup retention period (operator-tunable 1-35 days, ≥7 institutional default), snapshot encryption via DescribeDBSnapshots with explicit IncludeShared=false + IncludePublic=false, and the Aurora DB-cluster snapshot dimension (a public restore=all cluster snapshot is CRITICAL; cross-account HIGH; unencrypted HIGH); plugin 1150 adds SQS dead-letter queue presence (dual-mapped with CC7.1). The cadence dimension (recurring-scan attestation of restore-test outcomes) is what would move A1.2 to covered. PI1.5 (Stored items) is partial via the DynamoDB Audit Integrity plugin (1060). Substrate-only scope — full PASS requires application-tier Lambda Runtime Assurance. The renderer surfaces a ⚠ Coverage caveat line on every partial control so an auditor seeing FAIL/PARTIAL knows the boundary of what we evidenced.

What "Out of scope" means

A SOC 2 audit covers technical, administrative, and physical controls. NSAuditor AI evidences the technical-network-and-cloud slice. Everything else is genuinely not our job — pretending otherwise would create what auditors call "scope illusion": the false belief that buying a scanner replaces governance work. The renderer emits all 37 OOS controls with their reason text in every gap report so auditors immediately see the engine's known boundaries and don't have to guess what wasn't evaluated. Pair with a GRC platform (Vanta / Drata / Secureframe) for the governance layer.

What the auditor actually receives

Each --compliance soc2 run writes 10 files to out/<scan-id>/ (14+ when recurring-attestation is configured), every one with a .sha256 integrity sidecar.

The report you send

nsauditor-ai report --from <run> --format executive turns a finished scan into a single self-contained, print-ready HTML file: nothing is fetched when the auditor opens it, and an optional --brand puts your own mark on the cover page. --format jira writes a Jira-importer CSV instead — the column mapping is completed inside Jira’s own importer and is not validated against a live Jira instance. The executive report carries a container census: where finding-like records sit in a place the report does not read, the report names and counts them on the page, so a silence is disclosed rather than rendered as a clean result. Pro and Enterprise tiers.

The cover-page Scope Attestation

Every artifact opens with the same attestation block — this is the auditor's single source of truth for what was assessed:

• Report ID + generation timestamp (local clock only — NTP-synced generation timestamps are WITHDRAWN as of EE 0.45.0; use RFC 3161 trusted timestamping, opt-in via the NSAUDITOR_TSA_URL environment variable, for an independent time anchor)
• Assessment type — explicit Type-I disclaimer
• Scanner version (EE + CE, both pinned across all artifacts in the scan)
• Targets in scope — explicit CIDR / domains / cloud account IDs
• Targets explicitly excluded with one-line business justification each (missing justification flagged ⚠ NO JUSTIFICATION PROVIDED)
• Framework + version — SOC 2 (AICPA TSC 2017, with 2022 points of focus)
• Clock advisory — WITHDRAWN as of EE 0.45.0: the NTP drift status and probe-staleness classification are removed
• TSA policy OID (when configured) and version delta verdict (stable / changed / unknown)

How an auditor verifies the artifacts

Evidence integrity — three layered guarantees

SOC 2 evidence falls apart the moment an auditor finds a gap a security team could exploit. We engineered for the threat model where the security team itself is one of the actors.

1. Integrity (against bit-rot & unsophisticated tampering)

Cover page is part of the report bytes. .sha256 sidecars verify the report bytes. If the cover-page scope is wrong, the hashes won't match. Always written.

2. Non-repudiation (against an insider regenerating both)

Opt-in, and off unless you configure it: set NSAUDITOR_TSA_URL to a Time-Stamp Authority and each artifact ships a .tsr sidecar containing a Time-Stamp Response from an RFC 3161 Time-Stamp Authority (opt-in; nothing is timestamped unless you name one, and an offline-only posture refuses it outright rather than skipping quietly). The TSA's signature attests "this hash existed at <TSA timestamp>" — a third-party time floor an internal actor cannot backdate. Recommended TSAs: FreeTSA.org (free, testing), DigiCert / Sectigo / GlobalSign (paid commercial), or your internal corporate TSA.

3. Suppression non-repudiation

The compliance suppress command signs an approval with Ed25519 when NSAUDITOR_SIGNING_KEY names a key and the compliance report checks that signature for approvers whose identity-registry entry carries key material. The signature payload is NFC-normalized per RFC 5198 and capped at 64KiB. The registry binds approver names to public keys with authorization scopes (which frameworks an approver may authorize for); an entry may carry the approver's public key beside its fingerprint, and the fingerprint must equal the one computed from that key material or the registry is refused at load. Two axes are reported rather than one: verified answers whether the suppression should stand, and cryptoValid answers whether those bytes came from the named key — they diverge on a revoked key, which is what makes signing after revocation a cryptographic finding. A missing verdict means the report did not check, never that a check failed; the report renders “signed — not checked by this report”. Late-renewal flagging surfaces governance gaps as bands: HEALTHY / ACCEPTABLE / DEFICIENT / CRITICAL. Quarterly trend analysis catches degradation that single-point-in-time review would miss.

Suppression workflow

Every real scan produces findings the security team triaged out — false positives, accepted risks with compensating controls. SOC 2 auditors reject silent deletion (looks like under-reporting) but accept documented exclusions.

The compliance engine resolves the suppressions file in three steps — NSAUDITOR_SUPPRESSIONS when you set it (an absolute path is honoured verbatim, a relative one resolves against your working directory), then the per-scan folder if a file is genuinely there, then the --out base, which is where compliance suppress writes — and enforces three fields per suppression: a specific match, a non-empty rationale, and an approver. Suppressions missing any of these are rejected and the underlying finding stays in fail status — the engine refuses to silently absorb undocumented suppressions.

Per-status default expiry

• accepted_risk — 90 days (compensating controls decay; quarterly review is institutional norm)
• false_positive — 365 days (scanner-error classifications don't go stale)
• Caller can override via explicit expiresInDays

Where suppressions show up

Every suppression appears in Appendix B — Accepted Risks & False Positives with control ID, finding text, status (accepted_risk vs false_positive), approver, rationale, and renewal chain. Expired suppressions surface as report.expiredSuppressions[] with a "REVIEW REQUIRED" callout when non-empty.

Operating-effectiveness over time

Recurring-scan attestation — compliance status taxonomy

• pass — scans within cadence, no scope drift
• pass_with_drift_review — within cadence; scope-drift events surfaced for CC8.1 change-management review
• cadence_breach — any inter-scan gap exceeds threshold (CC7.1 finding)
• no_evidence — zero scans in the window (distinguishes "scans on disk but outside window" from "truly empty rootDir" via discoveredCount)

SLA / MTTR tracking

Per-severity thresholds from sla.json. Three statuses per finding: compliant, approaching (default 75% of threshold), breached. The renderer separates breachedTotal (raw count) from breachedEffective (post-compensating-control). Auditors read both — breachedEffective > 0 is a hard CC7.1 finding. Suppressions with status: accepted_risk + non-empty compensating_control flip the effective status to breached_with_compensating_control; the renderer surfaces an inline disclaimer requiring auditor verification of each compensating-control text.

Opt-in GRC push (Vanta, Drata, Secureframe)

The Vanta, Drata, and Secureframe connectors map NSAuditor findings to each platform's evidence objects (e.g. Vanta TestResult; Secureframe uses the records model — NSAuditor pushes structured control records to the workspace evidence collection and your Secureframe rules evaluate them, the connector carrying the control status verbatim) and push them opt-in at scan time — you choose when to share. All three are early-access and single-workspace (not a multi-tenant sync); Secureframe's API shape is published-assumed and live-tenant validation is in progress.

Outcome mapping (Vanta)

Reliability features

• Pre-flight — single-shot GET to vendor identity endpoint with AbortController timeout
• Streaming response cap — MAX_RESPONSE_BYTES=1MiB (CC7.1 input validation at vendor API boundary)
• Duration cap — maxTotalDurationMs=180s per push (A1.2 availability bound under Retry-After saturation)
• Foreign-token detection — 18 well-known non-GRC token format patterns (GitHub, Slack, AWS, OpenAI, Stripe, GCP, npm) prevent misconfigured tokens reaching Vanta
• Idempotency — idempotencyKey() with scanId collision disambiguation (~<sha16> suffix)
• Description truncation — control descriptions truncate at 8KB with explicit count + scan reference

Is Nsasoft itself SOC 2 audited?

A direct answer to the most common procurement question. We're transparent about what we do and don't have.

Short answer

No, and we don't currently need to be. NSAuditor AI runs entirely on customer infrastructure. Scan data, findings, reports, and credentials never touch Nsasoft servers. License validation is offline (JWT with embedded public key). AI analysis uses customer-provided API keys (OpenAI, Claude, Ollama). We are not a data processor under any regulation.

Why most security vendors need SOC 2 (and we don't)

SaaS GRC platforms, MDR services, and cloud SIEMs all ingest customer security telemetry into their own infrastructure. They are data processors. SOC 2 attestation is the table-stakes proof that they handle that data competently — DPAs and BAAs are required, vendor security reviews are required.

NSAuditor AI is the inverse architecture. The product is a CLI / scanner / MCP server that runs in your environment. It produces files you keep. The only network traffic between you and us is npm package installs and (if you're an Enterprise customer) license-key purchase & renewal — all of which happen through standard npm and Stripe infrastructure. We have nothing of yours to safeguard.

What we offer instead of an attestation

• Architecture verifiability. The Community Edition is MIT-licensed open source. You can inspect the entire scanner. The Enterprise Edition follows the same architectural model — you can run tcpdump against it and prove the ZDE claim.
• Offline license validation. ES256 JWT with the public key embedded in the CE platform. No phone-home for license checks, even on Enterprise.
• Air-gapped operation for OT and regulated environments — installed from the npm registry and run entirely on your own infrastructure, with no outbound calls at scan time.
• The product produces SOC 2 evidence for you (this page). That's the relevant security claim — it shifts SOC 2 attestability to the customer's audit, where it actually belongs.

Future plans

If we ever begin processing customer data — for example a hosted GRC service or a SaaS dashboard layer — we will pursue SOC 2 Type II at that point and will publish the attestation here. Until then, the honest answer is "we don't need it, and we'd rather you didn't trust us than perform a compliance theater."

Questions your CPA firm asks, answered up front

How do I verify the scope of this report wasn't manipulated post-scan?

Three layered guarantees: integrity via SHA-256 sidecars on every artifact (always written, verifiable with shasum -a 256 -c); non-repudiation via opt-in RFC 3161 trusted-timestamp .tsr sidecars, written when NSAUDITOR_TSA_URL names a Time-Stamp Authority and absent when it does not; suppression non-repudiation via Ed25519 signatures checked against the identity registry for approvers whose entry carries key material, with a missing verdict meaning not checked rather than failed.

What if the security team marked a real finding as "false positive" to make the report look clean?

Multiple controls prevent this: every suppression is logged in Appendix B with rationale + approver; suppressions renewed after expiration are flagged LATE or VERY_LATE; quarterly trend analysis surfaces governance degradation. (Ed25519 suppression signing and identity-registry cross-reference run for approvers whose registry entry carries key material, and a missing verdict means the report did not check rather than that a check failed.)

How does the scanner handle clock drift?

WITHDRAWN as of EE 0.45.0 — the NTP clock attestation, its drift probe, its strict mode and its probe-staleness classification are removed from the product and are no longer claimed. Two measured reasons: it attested this scanner’s own host clock, while every framework time-synchronisation control asks about the customer estate; and over unauthenticated UDP it accepted any well-shaped reply, so the assurance never matched the word beside it. Report time is anchored instead by RFC 3161 trusted timestamping, opt-in via the NSAUDITOR_TSA_URL environment variable, whose token takes its time from the Time-Stamp Authority rather than from this host. The cover-page scope attestation still carries its ntp block, now with constant values and a note stating that this scanner does not measure its own clock.

This is a single-point-in-time scan. How does Type II apply?

NSAuditor AI EE supports Type II evidence via recurring-scan attestation, SLA / MTTR tracking with per-severity thresholds, version-delta detection across scans, and quarterly suppression-renewal cadence trend analysis with governance bands.

Why is CC1 (control environment) marked out of scope?

CC1 is about board oversight and organizational ethics — these are inherently human / process artifacts, not network state. We could pretend, but pretending creates more audit risk than admitting the boundary. Pair NSAuditor AI EE with a GRC platform (Vanta / Drata / Secureframe) for the governance layer.

Where can I see the canonical mapping?

The source of truth is data/compliance/soc2.json in the EE package. The full SOC 2 coverage matrix in the EE repo mirrors that file, and a test asserts the two stay in sync. The customer-facing version is at nsauditor.com/ai/docs/soc2/.