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, not substitute for a security assessment or an executed transfer agreement.
Operator means Jolts Inc.. Contact: 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.