Controls Evidence Map
How our controls map to the frameworks your auditor uses.
A SOC 2 auditor or internal compliance reviewer starts here. Each row names a control, what evidence backs it, and its current status: Operating, Partial, or Pending. Items marked Operating have evidence in our codebase, runbook, or shipped artifacts; items marked Pending are tracked on our internal security roadmap with target close dates shared under NDA.
How this map is maintained
Discipline behind the table.
- Evidence is named in the row rather than left implicit, and points at a shipped artifact, a chart template, a runbook section, or a named mechanism in the product.
- This map is refreshed by hand when the thing it describes changes. There is no automated check that catches a row going stale, so if you find one that has, tell us and we will treat it as a finding rather than a typo.
- Cross-reference depth: this map points to the artifact; the artifact points to the test, metric, or runbook that proves it.
- Status moves from Pending to Operating when the corresponding work on the internal security roadmap closes.
- For an external auditor walk, every Operating row should map to a test that exercises the control plus a runbook entry that describes how to handle failures.
SOC 2 Trust Services Criteria
Current control posture against SOC 2.
We do not hold a SOC 2 report today. We hold scoped fixed-fee quotes and begin the engagement when a customer engagement requires one; Type II then follows its required observation period. The rows below are our current self-assessment, not an auditor's attestation.
CC1. Control environment
Control
Evidence
Status
CC1.1 Demonstrates commitment to integrity and ethical values
Sparcle Proprietary License; founder code-of-conduct (internal)
Operating
CC1.2 Board oversight
Sparcle Inc. is incorporated in Delaware; no independent board seated yet
Pending
CC1.3 Organizational structure
Same as CC1.2
Pending
CC1.4 Personnel competence
Background-check policy on the internal security roadmap
Pending
CC1.5 Accountability for internal controls
Policy pack rollout on the internal security roadmap
Pending
CC2. Communication and information
Control
Evidence
Status
CC2.1 Quality information for internal control
Operations runbook, PII architecture doc, disaster-recovery doc, SIEM export guide (shared under NDA)
Operating
CC2.2 Internal communication of objectives and responsibilities
Annual security awareness training on the internal security roadmap
Pending
CC2.3 External communication
This evidence map; Sub-Processor Disclosure; published compliance README
Operating
CC3. Risk assessment
Control
Evidence
Status
CC3.1 Specifies suitable objectives
Internal production-readiness audit (available under NDA)
Operating
CC3.2 Identifies and analyzes risk
Internal risk register (available under NDA); 30+ classified S1-S4 risks
Operating
CC3.3 Considers potential for fraud
Policy pack on the internal security roadmap
Pending
CC3.4 Identifies and assesses changes
Change-management policy on the internal security roadmap
Pending
CC4. Monitoring activities
Control
Evidence
Status
CC4.1 Ongoing and separate evaluations
Prometheus and curated alerts in the Helm chart; planned annual penetration test on the internal security roadmap
Partial
CC4.2 Internal communication of deficiencies
Incident response framework published at /trust/incident-response: five phases, named intake at [email protected] via /.well-known/security.txt, acknowledgement and patch targets stated per severity
Operating
CC5. Control activities
Control
Evidence
Status
CC5.1 Selects and develops control activities
Helm chart with hardened defaults
Operating
CC5.2 Selects and develops technology controls
Operations runbook, Production Hardening Checklist (shared under NDA)
Operating
CC5.3 Deploys through policies and procedures
Policy pack rollout on the internal security roadmap
Pending
CC6. Logical and physical access
Control
Evidence
Status
CC6.1 Logical access security
Session middleware, admin-only middleware, per-handler OAuth scope checks, identity module, authorization module. Source-IP restriction and mTLS on admin endpoints are ingress-layer controls you configure; the chart does not ship them.
Operating
CC6.2 Authorization and authentication of users
Authorization enforcement module, CSRF middleware (enforcing by default), SCIM 2.0 server at the standard /scim/v2/* mount point: full Users CRUD, with group membership set through the Users PATCH surface rather than a separate /Groups endpoint
Operating
CC6.3 Modification or removal of access
SCIM token issue / list / revoke via an authenticated admin endpoint
Operating
CC6.4 Restricts physical access
Not applicable. Sparcle does not operate physical infrastructure; customer-owned cloud.
Operating
CC6.5 Discontinues access
GDPR right-to-erasure module; per-org KMS crypto-shred via an authenticated admin endpoint
Operating
CC6.6 Restricts external access
Helm chart NetworkPolicy template, default-deny with explicit allow, enabled in the production values file. Source-IP restriction and mTLS are yours to add at the ingress; we do not ship them and do not claim them.
Partial
CC6.7 Transmission of data
TLS at ingress (cert-manager); HSTS and security headers; session cookies Secure and SameSite
Operating
CC6.8 Prevention and detection of unauthorized software
Cosign keyless signing and admission policies (Sigstore Policy Controller, Kyverno examples)
Operating
CC7. System operations
Control
Evidence
Status
CC7.1 Detection of vulnerabilities
Server (container) path: the Trivy gate blocks CRITICAL and HIGH against the pushed image digest with a non-zero exit, and cosign keyless signing runs only after it passes. The SBOM attached in that pipeline is the builder's SPDX attestation; the CycloneDX SBOM is produced by a separate step, not by that workflow. Desktop path: a two-tier gate runs a secret scan on every commit and a full secrets, advisory and licence scan at release against a frozen build point.
Partial
CC7.2 Monitoring of system performance
Prometheus metrics; 8 alert groups plus audit hardening alerts in the chart
Operating
CC7.3 Evaluation of security events
Merkle-sealed audit chain covering authorization decisions, retrieval access, tool invocations, model calls, agent decisions, admin policy changes, the security-relevant identity transitions (sign-in, sign-out, session delegation and revocation, session attach) and the privileged key and identity operations (KMS rotation and crypto-shred, PII reveal, SCIM token issue and revoke). It does NOT yet cover the audit-seal operation itself, which still emits a log line rather than a sealed record; OAuth token refresh and the read-only SCIM token list are excluded on purpose and pinned by tests. SIEM forwarder with Splunk, Sentinel and syslog backends, off by default.
Partial
CC7.4 Incident response
Operations runbook, Incident Workflow (shared under NDA; summarized publicly on /trust/incident-response)
Operating
CC7.5 Recovery from incidents
Disaster-recovery documentation (shared under NDA)
Operating
CC8. Change management
Control
Evidence
Status
CC8.1 Authorizes, designs, develops, configures changes
Develop and configure: CI workflow (push and PR triggers), deploy workflow with Trivy gate, signed release artifacts. Authorize: independent pre-merge review is being introduced for changes to authentication, cryptography, licensing, the audit chain, and egress paths; today automated gates approve the merge. Until that review control is operating, we do not claim this criterion in full.
Partial
CC9. Risk mitigation
Control
Evidence
Status
CC9.1 Identifies, selects, develops risk mitigation
Backup CronJob in chart with fail-closed S3 destination guard
Operating
CC9.2 Assesses and manages risks of business partners
Sub-Processor Disclosure
Operating
HIPAA Security Rule
Per-standard implementation map.
Sparcle ships HIPAA-deployable software that customers run in their own infrastructure. The rows below map Sparcle's software-vendor-side controls and BAA-able support to the HIPAA Security Rule; a Business Associate Agreement is executable per customer. Customer-side controls (PHI handling in the customer's environment, breach reporting under their BAAs with their LLM and cloud providers) remain with the customer per the deployment topology.
Standard
Implementation specification
Evidence
Status
164.308(a)(1)(i) Security Management Process
Required risk analysis
Internal risk register
Operating
164.308(a)(3) Workforce Security
Authorization / supervision / termination
Pending on the internal security roadmap
Pending
164.308(a)(5) Security Awareness and Training
Required
Pending on the internal security roadmap
Pending
164.308(a)(6) Security Incident Procedures
Required response
Operations runbook, Incident Workflow
Operating
164.308(a)(7) Contingency Plan
Required backup and DR
Disaster-recovery documentation; backup CronJob
Operating
164.312(a)(1) Access Control
Unique user id, automatic logoff, encryption
Session middleware; CMK envelope encryption
Operating
164.312(b) Audit Controls
Required
Merkle-sealed audit chain
Operating
164.312(c) Integrity
Required
Audit-chain Merkle root and Ed25519 signing
Operating
164.312(d) Person or Entity Authentication
Required
OIDC, SAML, SCIM via identity module
Operating
164.312(e) Transmission Security
Required encryption
TLS ingress and DB TLS (SSL_MODE=require)
Operating
164.314(a) Business Associate Contracts
Required
Customer BAA template; Anthropic BAA in progress
Pending
GDPR
Article-by-article map.
Article
Requirement
Evidence
Status
Art. 5(1)(f) Integrity and confidentiality
Appropriate security
Aggregate of CC6 and CC7 above
Operating
Art. 17 Right to erasure
Erasure on request
Per-org crypto-shred via an authenticated admin endpoint; tenant-scoped KMS shred at the trait layer (LocalKms production-tested; AwsKms, VaultKms reference impls in integration testing)
Operating
Art. 25 Data protection by design
Pseudonymization and encryption by default
PII pseudonymization at LLM boundary and at tool-result to history boundary; CMK envelope encryption
Operating
Art. 28 Processor obligations
Sub-processor disclosure and DPA
Sub-Processor Disclosure
Operating
Art. 30 Records of processing activities
Required logging
Audit chain and customer-side SIEM forwarder
Operating
Art. 32 Security of processing
Pseudonymization, encryption, resilience, testing
Aggregate of above
Operating
Art. 33 Notification of personal-data breach
72-hour notification
Incident response framework published at /trust/incident-response, with contractual notification in the executed DPA. Sparcle holds no customer personal data, so the controller notification duty sits with the customer; we supply what they need to meet it
Operating
Art. 35 DPIA
Required for high-risk processing
Customer-driven (Sparcle is the processor; controller does the DPIA)
Pending
ISO 27001
Selected Annex A controls.
ISO 27001 is not in flight for Year 1. The rows below are alignment evidence; formal certification is a separate engagement.
Annex A
Control
Evidence
Status
A.5 Information security policies
Policies in place
Pending on the internal security roadmap
Pending
A.8 Asset management
Asset register
Internal asset register
Pending
A.9 Access control
Authorisation, removal
Same as CC6
Operating
A.10 Cryptography
Key management
Pluggable KMS via aeira-traits Kms trait (Local production-tested; AWS, Vault reference impls in integration testing); cosign signing for releases
Operating
A.12 Operations security
Logging, monitoring, vulnerability management
Same as CC7
Operating
A.13 Communications security
Network security
Helm NetworkPolicy; TLS
Operating
A.14 System acquisition, development, maintenance
Secure development
Secure SDLC policy pending on the internal security roadmap
Pending
A.16 Information security incident management
Incident response
Operations runbook, Incident Workflow
Operating
A.17 Business continuity
Plan and tests
Disaster-recovery documentation
Operating
A.18 Compliance
Regulatory compliance
This map
Operating
Status key
What the labels mean.
- Operating. Control is implemented and evidence exists in the codebase, runbook, or shipped artifacts.
- Partial. Control is partially implemented; the gap is named in the Evidence column.
- Pending. Control is not yet implemented; closure is tracked on the internal security roadmap.
Need to map a control we have not listed?
Version 0.2. Counsel and SOC 2 auditor review pending.