# Security, retention and subprocessor schedule

Proposed security, retention and vendor disclosures.

Draft preview · No effective date

[Read as Markdown](https://jolts.xyz/legal/security-and-subprocessors.md)

**DRAFT — NOT EFFECTIVE. Proposed launch requirements, not verified security representations.** No customer should be told that these controls are implemented until the evidence register is completed. This schedule is intended to accompany the [DPA](https://jolts.xyz/legal/data-processing-addendum), not substitute for a security assessment or an executed transfer agreement.

Operator means **Jolts Inc.**. Contact: **[contact@jolts.xyz](mailto:contact@jolts.xyz)**. The operative version, scope and approval date must be recorded in the executed agreement. Identity placeholders are centrally managed; do not copy an entity name, domain or supplier identity into multiple legal documents.

## 1. Deployment boundary and evidence

The current repository contains a marketing website and enquiry storage. Configuration templates and application code do not prove production deployment, infrastructure security, service-provider contracts or access restrictions. The planned advertising API, campaign management, tracking, payments and conversation storage need a separate verified data-flow map before this schedule can be offered contractually.

Record **[DECISION: system owner, deployment identifier, regions, production services and approval authority]**. Each control below needs an owner, implementation description, dated evidence and any exception. An exception must identify compensating controls, residual risk and a deadline; it does not silently amend an executed customer commitment.

## 2. Proposed baseline controls

| Area | Required design before approval | Evidence to retain |
| --- | --- | --- |
| Identity and access | Individual administrative identities, strong authentication, least privilege, separate production permissions, timely offboarding, approved emergency access | Access matrix, authentication configuration, access review and offboarding record |
| Secrets | Managed secret storage, scoped credentials, rotation/revocation process, no secrets in source or logs | Inventory without secret values, scanner results, tested rotation procedure |
| Customer separation | Enforce authorization for each publisher, advertiser and administrative operation; protect exports and reporting from cross-customer access | Architecture and negative authorization tests, scoped data-access review |
| Transport and storage | Document encryption in transit and at rest, key custody and coverage; restrict unencrypted exports and debug captures | Actual protocol/storage settings and key-access evidence; no unsupported algorithm claims |
| Conversation handling | Defined request fields, size limits, minimization, sensitive-data rejection/redaction and approved retention; no conversation bodies in routine logs | Schema, payload samples using synthetic data, redaction and deletion tests |
| Tracking and consent | Record the purpose and lifetime of each identifier; enforce required user choices and publisher signals; no silent cross-app joining | Technology inventory, choice tests, event-flow diagram and consent/opt-out handling |
| Logging | Audit material administrative and security events; restrict log access; filter credentials, conversation content and unnecessary personal fields | Log inventory, sampled synthetic output, access controls and expiry settings |
| Software delivery | Reviewed changes, dependency and vulnerability checks, production separation, rollback process | Build records, review evidence, remediation decisions and rollback rehearsal |
| Availability and recovery | Protected backups, documented restoration, defined recovery objectives based on actual architecture | Restore-test results and agreed recovery objectives; a backup setting alone is insufficient |
| Incident response | Named responders and escalation, containment/evidence procedure, customer notice workflow, periodic exercises | Incident plan, contact validation, exercise report and follow-up actions |
| Suppliers | Contract and security due diligence before data access; validate subprocessors and restricted transfers | Executed supplier terms, processing locations, risk assessment and register |
| Deletion and export | Tested user/customer deletion propagation, retrieval format, backup expiry and legal-hold isolation | End-to-end tests and deletion/export records |

**[DECISION: finalize control scope, review cadence, vulnerability priority definitions, remediation targets, incident-notice target and recovery objectives.]** Do not insert attractive timelines unless staffing and tooling can deliver them. These proposed controls do not establish SOC 2, ISO 27001, PCI DSS or any other certification or audit status.

## 3. Retention matrix

Approve a maximum or event-based retention rule for each category before collection. "As long as necessary" is not an implementation setting. A customer's configured period cannot exceed an applicable contractual or legal limit.

| Category | Purpose to validate | Period and deletion trigger |
| --- | --- | --- |
| Website enquiries and follow-up | Respond to a request and maintain necessary business records | [DECISION: active enquiry, closed enquiry and deletion-request rules] |
| Raw ad-request context | Perform the specific matching operation | [DECISION: transient processing or narrowly justified storage; default must be deliberate] |
| Stored conversation text | Specifically approved Customer purpose | [DECISION: explicit opt-in scope, active retention and deletion propagation] |
| Impression/click/conversion events | Agreed measurement, billing and dispute resolution | [DECISION: field-level event retention, aggregation and unlinking dates] |
| Poll responses | Voluntary research purpose disclosed to respondents | [DECISION: identifiable response lifetime and aggregation threshold] |
| Security and fraud records | Protect systems and investigate identified abuse | [DECISION: minimization, access, case hold and expiry] |
| Billing/tax records | Accounting and legal requirements | [DECISION: jurisdiction-specific period; separate from conversational data] |
| Backups | Recovery of approved systems | [DECISION: expiry cycle, beyond-use safeguards and restored-deletion replay] |

Aggregation is not automatically anonymization. Document whether people can reasonably be singled out, linked or inferred from an output before treating it as non-personal. Hashing a persistent identifier does not itself authorize unlimited retention or unrestricted sharing.

## 4. Subprocessor register — no providers approved yet

Do not infer a supplier appointment from a Gemfile dependency, deployment template or proposed architecture. Identify actual contracted legal entities, not merely product names.

| Legal entity | Service and purpose | Customer Data accessed | Processing/remote-access countries | Transfer mechanism | Contract/due-diligence evidence | Approval/change date |
| --- | --- | --- | --- | --- | --- | --- |
| [DECISION: actual provider] | [Function] | [Fields/categories] | [Countries] | [Applicable mechanism or reason none is required] | [Evidence reference] | [Date] |

Review hosting, databases, object storage, support, monitoring, email, analytics and model providers individually. A payment provider may act as an independent controller for some processing; record that distinction in the data map instead of automatically listing it as a subprocessor. Likewise, an advertiser receiving data for its own purpose is not made a subprocessor by this register.

The register must link to the DPA's agreed advance-notice and objection procedure. **[DECISION: where the current register and archived versions are accessible; notice channel; person responsible for supplier updates.]** A website edit alone is not advance notice where the contract requires direct notice.

## 5. Customer responsibilities and verification

Customers must protect their credentials and endpoints, restrict their own personnel, send only authorized data and implement the agreed disclosure/choice mechanism. Operator must verify required signals and contractual safeguards at its boundary; it must not shift its own duties to Customer merely because Customer collected the data first.

Before activation, jointly review a synthetic request-to-report flow, including no-match behavior, a rejected sensitive payload, a deletion request, withdrawn tracking permission, a disputed event and termination/export. The completed result should identify what works, what is untested and what is disabled. No live-person conversation is required to demonstrate the flow.

## 6. Publication and maintenance

Keep this working schedule private until its factual statements are verified and contractual choices approved. A future public security page should describe substantiated controls in plain language and avoid operational details that create security risk. Confidential review materials may be shared through a controlled process without implying an audit certification.

Review the schedule after material architecture, purpose, supplier or location changes and on **[DECISION: periodic review cadence]**. Keep version history and customer notices required by the contract. Do not weaken an existing commitment through an unannounced documentation change.