Data Processing Addendum

ShieldScore offers a Data Processing Addendum for customers that require contractual privacy and data handling commitments in connection with their use of the service.

Requesting a DPA

To request our current DPA template, email privacy@shieldscore.ai with your company name, billing contact, and primary privacy contact.

Scope

Our DPA covers the processing of customer data submitted to ShieldScore for the purpose of providing the compliance automation platform, subject to the customer's subscription agreement and applicable law.

Customer Data Retention Clause

For organizations operating under a paid subscription, ShieldScore enforces tier-explicit and framework-explicit retention floors on customer-controlled audit-log and evidence data, applied programmatically by per-organization cron. The clause below is incorporated by reference into our DPA for any customer with an active paid subscription.

5.Y — Customer Data Retention. Where a customer operates a paid ShieldScore organization under an active subscription, ShieldScore shall apply the following retention discipline on customer-controlled data:

• Tier-floor retention: customer audit-log and evidence retention shall not fall below the floor associated with the customer's active subscription tier — 365 days for Starter and Growth; 90 days for Professional and Enterprise. Workspace administrators may configure retention above this floor through in-app controls but cannot reduce it below the floor while the subscription is active.
• Framework-floor retention: where the customer's enabled compliance frameworks impose longer retention requirements, ShieldScore shall apply the larger of the tier floor and the framework floor automatically. As of this writing, HIPAA imposes a 2,190-day evidence floor (45 CFR §164.316(b)(2)) and PCI DSS imposes a 365-day evidence floor (PCI DSS Req. 10.7). Other enabled frameworks default to the tier floor unless their explicit regulatory floor is encoded in a future release. When multiple frameworks are enabled, the applied floor is the maximum across them.
• Audit-log soft-delete with chain preservation: at the retention boundary, ShieldScore shall soft-delete audit-log rows by setting deletedAt and emitting an accompanying change-history audit-log entry, preserving the Merkle chain across the soft-delete so historical chain verification remains valid for the data that has been soft-deleted.
• Customer-rights interaction: nothing in this clause limits the customer's deletion or export rights under applicable privacy law, except that ShieldScore may continue to retain evidence subject to an in-force framework regulatory floor (HIPAA §164.316 or PCI DSS Req. 10.7) until that floor elapses, after which deletion proceeds in accordance with that customer right.
• Production-org isolation from demo automation: organizations classified orgType=PRODUCTION are exempt by code-level guard from the Tombstone Two-Timer demo-sweep mechanism described in §5.X. Customer-initiated offboarding follows the customer-rights path described above, never the automated demo-sweep path; the demo-sweep cron contains an explicit precondition check that excludes any organization whose orgType is not DEMO.

Demo Data Retention Clause

The ShieldScore public demo experience creates an ephemeral organization scoped to a single browser session, which is governed by our published retention discipline rather than the standard customer-data retention commitments. The clause below is incorporated by reference into our DPA for any customer whose users have interacted with the public demo prior to executing a subscription agreement.

5.X — Ephemeral Demo Data. Where an end user creates an ephemeral demo organization via the public demo entry point at shieldscore.ai, ShieldScore shall enforce the following retention discipline on the demo organization and its cascade data:

OrgType classification. ShieldScore's data model classifies every organization under one of four orgType values: DEMO (governed by this §5.X), PRODUCTION (governed by §5.Y), FIXTURE (test-infrastructure organizations used in CI / structural-contract testing, never customer-visible), and INTERNAL (ShieldScore-internal operations, never customer-facing). The Tombstone Two-Timer mechanism applies only to DEMO; the remaining three values are out of its scope by code-level guard.

• Soft-tombstone shall be applied at createdAt + 1 hour + grace, suspending all access to the demo organization while preserving audit-log Merkle-chain integrity for compliance evidence retention.
• Hard-purge shall be applied at tombstonedAt + 90 days (environment-tunable via TRUST_CENTER_DEMO_RETENTION_DAYS; the customer may request the operational value in writing via the address above) once the T2 hard-purge mechanism exits DRY_RUN observation and flips to LIVE (target 2026-06-13); the mechanism causes cascade child rows to be FK-rewritten to a per-organization system sentinel actor. Current substrate state and the substrate-gap disclosure are published at /incidents/r13-ac.
• PII handling across T1 and T2: at T1 (soft-tombstone) the demo organization is marked tombstoned and authentication is blocked, but no cascade User PII is scrubbed — the signed deletion receipt produced at T1 carries scrubMechanism: "t1-tombstone-only" reflecting that semantic. At T2 (hard-purge, once the stored retentionUntil elapses), every cascade User's email is replaced with a cryptographically random placeholder on RFC 2606 reserved TLD ( redacted.invalid); display name is set to NULL; MFA recovery codes are deleted; rate-limit event telemetry rows scoped to the organization have ip, userAgent, cfRay, and cfCountry fields set to NULL. T2 pseudonymization runs in a pre-pass; the subsequent per-organization Serializable transaction writes FK rewrites, the organization soft-delete, and the ORG_HARD_PURGED audit-log row together.
• T2 eligibility revalidation shall re-query the organization's eligibility predicates (orgType, tombstonedAt, retentionUntil, deletedAt) inside the per-organization Serializable transaction immediately before writing the T2 audit-log evidence. A stale candidate (already soft-deleted by another runner, or with shifted retentionUntil) is silently skipped without producing audit evidence. The historical one-shot L2 backfill script at scripts/backfill-r13-ac-stale-demo-orgs.ts retains stricter pre-tombstone C3 invariant assertions on image, passwordHash, mfaSecret, and stripeCustomerId, halting the run on non-conforming rows; that is the operator-driven backfill behavior, not the recurring T1/T2 substrate behavior.
• Signed deletion receipts shall be emitted per tombstone event, signed (RS256 via AWS KMS) with the ShieldScore Trust Center signing key currently published at https://api.shieldscore.ai/.well-known/jwks.json. Receipts follow the shieldscore/deletion-receipt/v2 schema and are independently customer-verifiable from the published surfaces alone. The clause below describes the receipt payload shape, canonicalization standard, customer verification procedure, historical-kid verification path after rotation, and ShieldScore-side receipt retention asymmetry.
  • Payload field roster (v2): every receipt envelope contains the following top-level fields: schema (literal shieldscore/deletion-receipt/v2), receiptId (UUIDv4, stable per-receipt handle for customer audit-trail cross-reference), issuedAt (ISO 8601, timestamp at canonicalization — distinct from tombstonedAt), runId, orgIdRedacted, tombstoneReason, tombstonedAt, retentionUntil, retentionDays, scrubMechanism (literal union: t1-tombstone-only or cuid_replacement_random_email_local_part), scrubbedEmailDomain, affectedCounts, piiInvariantVerification, kidStatusAtSigning (literal ACTIVE or RETIRING; signing with a RETIRED kid is fail-closed at the service layer), jwksUri, jwksHistoryUri, decisionProvenance, and signature (envelope containing alg=RS256, kid, value, and canonicalization=rfc8785).
  • Canonicalization: receipt payloads are canonicalized using RFC 8785 JSON Canonicalization Scheme (JCS) before signing. The signature covers the entire payload object with the signature field stripped; verifiers reconstruct the canonical form by applying RFC 8785 to the received payload minus its signature field.
  • Customer verification procedure: to verify a deletion receipt independently, (1) recompute the RFC 8785 canonicalization of the receipt payload with the signature field stripped; (2) load the verification key by routing on the receipt's signature.kid field — fetch the JWK Set at jwksUri first, which returns a standard RFC 7517 document containing every kid currently in the ACTIVE or RETIRING lifecycle state; if the kid is found there, the matching JWK entry is the verification key; if not, fetch the kid timeline at jwksHistoryUri and locate the matching entry — if that entry has kmsKeyVerifiable: true and a non-null publicKeyPem, that PEM is the verification key; if the entry has kmsKeyVerifiable: false or publicKeyPem: null (e.g. the R13.AG orphan kid), the signing key material is not recoverable and cryptographic verification is not available — the entry's incidentArtifactRef field points to the sealed incident-archive endpoint for that kid's documented disposition, and the receipt should be treated as an incident artifact bound to that disposition rather than as an independently signature- verifiable document; (3) when a verification key was loaded in step 2 (the recoverable case), verify the canonical bytes from step 1 against the receipt's signature.value using RS256. No call to ShieldScore is required for verification beyond fetching the two public endpoints.
  • Kid rotation + historical verifiability: the active Trust Center signing kid follows a three-state lifecycle — ACTIVE, RETIRING (14-day overlap during rotation; still signs), and RETIRED (no longer signs). Receipts signed under an earlier kid whose key material is recoverable remain cryptographically verifiable after rotation via the /jwks-history endpoint, which returns the full kid timeline including per-entry status, activatedAt, retiredAt, kmsKeyVerifiable, and (when key material is recoverable) publicKeyPem. Where a kid's entry shows kmsKeyVerifiable: false and publicKeyPem: null — for instance, the R13.AG orphan kid ts-v1-2026-04-25 whose key material is not recoverable — the kid is not rehabilitated by the schema bump and receipts signed by it are not independently signature-verifiable; the entry's incidentArtifactRef field points to the sealed incident-archive endpoint that documents the disposition of that kid's historical artifacts. Any future kid that experiences an unrecoverable- key-material event would follow the same non-rehabilitation treatment.
  • ShieldScore-side receipt retention: every receipt is persisted by ShieldScore as part of the associated audit-log row (action="EPHEMERAL_DEMO_TOMBSTONED", metadata.deletionReceipt). Audit-log retention is tier-based per the customer's active subscription — 365 days at Starter and Growth; 90 days at Professional and Enterprise — and is enforced by the audit-log retention cron, which soft-deletes rows past their retention boundary while preserving the Merkle chain. The audit-log row is not cascade-deleted when the demo organization is hard-purged at T2; it follows its own retention schedule. Customers who require an indefinitely retained copy of any specific receipt should save the receipt envelope client-side at receipt-emission time; ShieldScore does not guarantee receipt availability beyond the audit-log retention floor described in the Customer Data Retention Clause (§5.Y).
• Sub-processor accountability (Stripe): ShieldScore's demo flow does not create Stripe customer objects (the demo path is unauthenticated and writes only local ephemeral state), so the recurring PR-γ T1/T2 substrate does not perform a per-tick Stripe sweep — no new Stripe sub-processor exposure is introduced at T1 or T2 that would warrant per-tick re-verification. To verify the absence empirically at the historical L2 backfill event (2026-05-17), the L2 backfill ran a post-execute read-only Stripe Customer search per tombstoned organization and recorded the result in the L2 audit artifact as stripeCustomersVerifiedAbsent: 14 (14 of 14 verified absent). Should a future PR add per-tick Stripe verification to the recurring substrate, the same compile-time read-only Stripe wrapper will be reused.

The complete operational specification, executable mechanism, signed deletion receipt template, and self-verification audit query are published at /demo-data-handling. The decision record is maintained at docs/operational/sessions/2026-05-16-session-9.md in our public source repository.

No carve-out for analytics. Once the T2 hard-purge mechanism exits DRY_RUN observation and flips to LIVE (target 2026-06-13), ShieldScore shall not retain demo data beyond the 90-day hard-purge window for product-analytics or training purposes. Demo organizations already tombstoned by the historical R13.AC L2 backfill remain soft-tombstoned with signed deletion receipts and are subject to T2 hard-purge once the recurring sweep flips LIVE; newly T1-eligible demo organizations (those that age past the createdAt + 1 hour + grace boundary during the bridge window) are NOT newly tombstoned by the recurring sweep until the shared DEMO_ORG_SWEEP_DRY_RUN flag flips to LIVE on 2026-06-13, after which the next eligible LIVE T1 tick begins creating new tombstones plus signed receipts. Full substrate-gap disclosure is at /incidents/r13-ac. Aggregate non-identifying telemetry (e.g. count of demo organizations created per day) may be retained indefinitely; per-organization or per-user-identifiable telemetry shall not.