Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.
Vendor security review, the ritual: 'Are you SOC 2 compliant?' - 'Yes, here is our Type II report.' Box ticked, both parties move on. But that report only says controls were effective during the audit window. The control that breaks in Q2 stays 'compliant' on paper until the next audit in Q4 - and the gap between 'was effective then' and 'is effective now' is exactly where vendor-risk incidents live.
EU DORA, MAS TRM, and PCI DSS 4.0 increase demand for ongoing control evidence. QNSI source defines framework mappings and service-health-derived status, but liveness is not control-effectiveness proof. Tenant-specific effectiveness and deployment behavior remain NOT VERIFIED.
How QNSI source maps control status
QNSI source maps controls to named service-health inputs and computes status labels from those inputs. Health does not prove encryption, audit ingestion, or control effectiveness; complete tenant-specific evaluation remains NOT VERIFIED.
The engine covers 7 frameworks - SOC 2 Type II, HIPAA, GDPR, PCI DSS v4.0.1, ISO/IEC 27001, Singapore PDPA, and MAS TRM - and activation follows your crypto policy tier: strict lights up SOC 2, HIPAA and PDPA; maximum and government activate all seven, MAS TRM included.
Three gaps continuous evidence should detect
- Incident degradation: continuous evidence should identify a control failure during its actual window rather than inherit an annual snapshot.
- Configuration drift: continuous evidence should detect changed control state between audit windows.
- Tenant scope: control evidence should be attributable to one tenant rather than a platform-wide average. QNSI tenant-specific effectiveness remains NOT VERIFIED.
Evidence packs: what your auditor takes away
Auditors need durable deliverables in addition to current status. QNSI source defines framework-specific evidence-pack and ML-DSA audit contracts; complete generation, anchoring, provenance, and independent verification remain NOT VERIFIED.
And the deepest control of all - whether the cryptography itself is correct - is public. Hand your assessor this, no QNSI account required:
# No account required - QNSI's cryptographic base layer is publicly verifiable
curl -s https://qnsi.heossi.com/pqc-evidence/acvp-latest.json | \
node -e 'const j=JSON.parse(require("fs").readFileSync(0));console.log(j.summary)'
# Human-readable evidence + integrity digest:
# https://qnsi.heossi.com/verify/conformanceWhat live evaluation does not replace
Formal SOC 2, ISO 27001, or HIPAA attestation remains distinct from operational telemetry. Service health alone cannot establish that a control is effective.
QNSI source colocates control mappings and service-health inputs. That architecture reduces reconciliation boundaries but does not independently prove control effectiveness or deployment behavior, which remain NOT VERIFIED.
The one question to add to your vendor questionnaire
Ask whether a vendor provides continuously attributable evidence in addition to snapshots, and how that evidence is independently verified. QNSI source defines a dashboard and evidence-pack contracts; tenant-specific effectiveness, signing, and deployment behavior remain NOT VERIFIED.
Start now
A workspace can be used to inspect the compliance surface at https://cloud.qnsi.heossi.com/auth?mode=signup. Dashboard output and service health are not independent proof of control effectiveness.
Folding this into a regulated audit cycle? Talk to a QNSI architect at /contact.