Acceptable Use & Asset Management Policy
This policy states stratify's commitments on knowing what information assets exist, how they may be used, how they are classified, and how records and intellectual property are protected. Where a control is genuinely not applicable at stratify's current stage, that is stated plainly rather than worked around.
1. Asset inventory (5.9)
register/assets.yaml is the asset register for this ISMS. It currently lists 13 real assets seeded directly from register/facts.md — the actual database tables, the production host, the source repository, backups, secrets storage, and the founder's laptop — not a hypothetical target-state inventory. This is an honest starting point, not a finished control: the register was populated once, on 1 August 2026, from known facts. It is not yet a maintained living inventory — there is no process that adds a new asset when one is created (e.g. a new database table added by a migration) or retires one when it's decommissioned. Control 5.9 is scored not_started in register/controls.yaml for that reason: the register existing is necessary but not sufficient: a maintenance procedure (a future procedures/PRO-15-asset-classification.md) is what would move this to implemented.
2. Acceptable use of company assets (5.10)
No acceptable-use policy exists yet in written form (register/controls.yaml 5.10, status not_started). Until a dedicated version is written, the following baseline rules apply as this policy's minimum commitment, consistent with practice already documented elsewhere in the repo:
- Laptop. The founder's laptop (
ASSET-011inassets.yaml) is the sole engineering endpoint.
It is used for source access, secrets handling via macOS Keychain, and production administration over Tailscale. No formal endpoint baseline (disk encryption confirmation, screen-lock timeout, EDR) is documented yet — this is the same gap POL-03 names under control 8.1. Home-office equipment is used without a documented siting/protection standard (Annex A 7.8, partial) — physical-security controls in the 7.x range are largely not_applicable at stratify because there is no company-controlled facility, but the laptop itself is real, owned equipment and is not exempt from acceptable-use expectations.
- Credentials. Secrets are never stored in
.envfiles or committed to the repository. Dev
secrets live in macOS Keychain, sourced via ~/.keychain-secrets.sh; production secrets are injected as Docker environment variables on the Hetzner host (docs/secrets.md, POL-04 §2). Sharing a credential outside this path (pasting into chat, a ticket, or a document) is not acceptable use.
- Source access. Access to the stratify repository is via GitHub account, individually
attributable. There is no shared or generic credential for source access.
3. Return of assets (5.11)
Scored not_applicable in register/controls.yaml. There is a single-person engineering team; no company-owned equipment has been issued to a second party. This control becomes relevant, and this policy will be revised to state a return process, the moment a second engineer or contractor joins and is issued equipment or credentials.
4. Information classification scheme (5.12)
register/assets.yaml header comment defines the classification scheme this policy adopts:
| Level | Meaning | Example (real table, from assets.yaml) |
|---|---|---|
| Public | Intended for open distribution; no confidentiality expectation | strategy_mandates — world-readable by design (supabase/migrations/0002_rls.sql:17); public pilots |
| Internal | Not published, but low sensitivity if disclosed internally | stratify source code repository; docs/compliance/dsgvo-data-flow.md itself |
| Confidential | Personal data or business-sensitive; disclosure would cause real harm | subscribers, signal_deliveries, waitlist, web_push_subscriptions |
| Restricted | Highest sensitivity — auth material, audit trail, privileged infrastructure access | audit_log, auth.users, partner_api_keys / partner_users, the production host, secrets storage, nightly backups |
This scheme is not aspirational — it is already structurally enforced for the restricted tier, not just documented: audit_log and signal_deliveries have Row-Level Security enabled with no SELECT policy at all, meaning the only read path is the service-role key (register/facts.md, "Database & access control"). Classification exists as a real fact about the schema before it exists as a written policy; this document is catching the documentation up to the implementation, not the reverse. Control 5.12 is nonetheless scored not_started in register/controls.yaml because no table has been formally walked and assigned a classification label outside of assets.yaml's initial seed — that pass is future work.
5. Labelling of information (5.13) — not applicable
Control 5.13 is scored applicable: false / not_applicable in register/controls.yaml. Stratify has no physical document-labelling regime, and none is needed: classification (§4) is enforced structurally, at the database layer, via Row-Level Security policy and schema design rather than via a label attached to a document or file. A restricted table doesn't carry a label that a person could ignore — the RLS deny-by-default policy makes unauthorized reads impossible through the application, independent of any human remembering to treat the data carefully. This is the correct architecture-appropriate substitute for 5.13, not an excuse to skip it.
6. Intellectual property rights (5.32)
No documented IP policy exists (register/controls.yaml 5.32, status not_started) — a real gap, not a nuance. The concrete open question is pilot-authored signal content: pilots (verified strategy authors, README.md) draft the trading signals distributed to subscribers, and there is no written determination of who owns that content, under what terms it's licensed to stratify, or what happens to it if a pilot relationship ends. A second, related question is AI-assisted content: signal drafts may pass through the Vercel AI Gateway → Anthropic path for German drafting assistance (register/facts.md, sub-processor table) — ownership and confidentiality treatment of that draft content is likewise undocumented. Both need a written IP policy before pilot volume grows past the current small, informally-trusted set of authors.
7. Protection of records (5.33)
Scored partial in register/controls.yaml. Stratify's database migrations (supabase/migrations/0001_init.sql through 0021+) are sequentially numbered and applied in strict order — this is a real, existing form of record protection for the schema itself: no migration can be silently reordered or skipped without breaking the chain, and the migration history is a permanent, git-tracked record of every schema change ever made. This is a genuine partial control, not a stretch: it gives the same tamper-evidence property for schema evolution that the audit-log chain-hash gives for row-level events (POL-04 §2).
What's missing is a broader records-retention policy beyond the per-table retention column already maintained in docs/compliance/dsgvo-data-flow.md §2 (e.g. "24 months Phase A" for signal_deliveries and audit_log, flipping to 7 years on FMA license grant). That table covers personal-data retention; it does not cover retention of operational records more broadly (CI run history, deploy logs, ADRs) or a general records-protection standard (backup integrity, access control on historical records) independent of the privacy angle. This is future work for privacy/PRIV-11 (Retention & deletion schedule) and this policy's own future procedure.
8. Control summary
| Control | Status (controls.yaml) | This policy's role |
|---|---|---|
| 5.9 Inventory of information and other associated assets | not_started | assets.yaml seeded, not yet a maintained inventory (§1). |
| 5.10 Acceptable use of information and other associated assets | not_started | Baseline rules stated here as an interim commitment (§2). |
| 5.11 Return of assets | not_applicable | Single-person team, no equipment issued to a second party (§3). |
| 5.12 Classification of information | not_started | Scheme defined and already structurally enforced for the restricted tier (§4); formal table-by-table pass not done. |
| 5.13 Labelling of information | not_applicable | Structural/DB-level enforcement substitutes for physical labelling (§5). |
| 5.32 Intellectual property rights | not_started | Real gap; pilot-authored content ownership is the concrete open question (§6). |
| 5.33 Protection of records | partial | Ledgered DB migrations are a real, existing control; broader records policy doesn't exist yet (§7). |
9. Review
This policy is reviewed on the cadence set at approval, and immediately whenever a second engineer or contractor is issued company equipment (triggering §3), or whenever a pilot agreement is drafted without a resolved answer to §6.