Physical & Remote-Working Policy

Satisfies Annex A 6.7 (remote working) and the full 7.x physical-security control family (7.1 through 7.14). Grounded in `register/facts.md` and `register/suppliers.yaml`; statuses match `register/controls.yaml`.

1. Policy statement

Stratify has no owned or leased office and no company-controlled datacenter. Production infrastructure is a single rented server from Hetzner Online GmbH (Nuremberg, Germany — register/suppliers.yaml SUP-002), and the team works distributed by default from home offices. Those two facts drive almost everything in this policy: most of the Annex A 7.x physical-security controls are scored not_applicable in controls.yaml, not because physical security doesn't matter, but because the physical facility those controls govern belongs to Hetzner, not to Stratify.

That distinction matters and is stated once, here, rather than repeated fourteen times: a control being `not_applicable` to Stratify directly does not mean physical security is unaddressed — it means it is delegated to a named supplier and tracked via the supplier relationship (POL-05/Supplier & Cloud Security, and `register/suppliers.yaml`), not owned or verified directly by Stratify. What Stratify has not yet done is formally collect or reference Hetzner's own physical-security certifications as evidence — suppliers.yaml records Hetzner's dpa_in_place as unknown and flags the supplier record itself as "URGENT" to complete, since Hetzner isn't even yet reflected in dsgvo-data-flow.md's processor table (SUP-002, cross-referenced to RISK-001). That gap belongs to POL-05 and PRO-10 (Sub-processor onboarding & review), not to this document — this document's job is to correctly attribute the 7.x controls to that relationship, not to close the evidence gap itself.

2. Delegated to Hetzner — the perimeter/facility cluster (7.1, 7.2, 7.3, 7.4, 7.11,

7.12, 7.13) — status: not_applicable

Six controls share one reasoning, stated once:

None of these describe anything Stratify itself operates. There is no Stratify-controlled datacenter, server room, or office with a perimeter to secure, entry to control, or utility infrastructure to maintain. The wait, what. Advisory registered address (the controller of record pending Stratify's own incorporation, per facts.md) is a standard commercial address, not a secured facility that any of these controls would meaningfully apply to either.

All seven are correctly scored not_applicable, and the corresponding physical responsibility sits with Hetzner as the infrastructure supplier (SUP-002). That relationship — not a Stratify-authored physical-security control — is what actually protects the production host's physical environment. This policy references it rather than duplicating Hetzner's own controls, which Stratify has no visibility into beyond whatever certifications Hetzner publishes.

3. Protecting against physical and environmental threats (7.5) — status: partial

Hetzner carries environmental-threat protection (fire suppression, power redundancy, and similar facility-level protections) for the production host, delegated exactly as described in §2. What has not been documented is the equivalent consideration for the founder's own home-office equipment — the laptop that is Stratify's only real owned hardware asset. This is scored partial rather than not_applicable because, unlike the facility-level controls in §2, this one does have a Stratify-side component (the laptop) that hasn't been addressed.

4. Working in secure areas (7.6) — status: not_applicable

No Stratify-designated secure physical work area exists, and none is planned — the team is distributed and single-person by design, not because a secure area was considered and rejected. This control does not apply to that model.

5. Stratify's own responsibility: remote-working security (6.7) — status: partial

What exists: the team works distributed by default — this is an established, current fact of how Stratify operates, not a future intention. What doesn't exist: a documented remote-working security policy stating the minimum bar for the equipment that connects to production systems and handles subscriber data.

Minimum bar, stated here as the policy commitment even though verification is outstanding:

• Full-disk encryption on the founder's laptop.
• Screen-lock enabled with a short auto-lock timeout.
• Host-level OS and security updates kept current, not deferred indefinitely.

None of these three has been formally verified or documented as actually configured today — they are very likely true in practice for a security-conscious sole engineer, but "probably true in practice" is explicitly not the same claim as "a documented, verified control," and this policy does not blur that distinction. Verifying and recording the actual state of these three items is the concrete, low-effort next action for this control.

6. Clear desk and clear screen (7.7) — status: not_started

No clear-desk/clear-screen policy is documented. This is low-relevance for a home-office, single-person team — there is no shared physical workspace where a stranger could see an unattended screen or a document left on a desk — but it is not zero-relevance (a laptop left unlocked in a café, for instance, is exactly the scenario this control exists for), and a one-line commitment costs nothing: lock the screen when stepping away from the laptop in any non-private location, and avoid leaving physical documents containing subscriber or signal data visible (in practice, this is rarely triggered — nearly all Stratify data lives in the application, not on paper — but the commitment is stated rather than assumed).

7. Equipment siting and protection (7.8) — status: partial

The founder's laptop is the primary, and effectively only, owned equipment asset — there is no server-room hardware, since production runs entirely on the rented Hetzner host (§2). No documented siting or protection guidance exists for the home-office setup (e.g., basic guidance on not leaving the laptop in a parked car, using a private rather than fully open home network for administrative work). Scored partial because the asset itself is correctly identified even though the guidance around it isn't written down.

8. Security of assets off-premises (7.9) — status: not_started

No policy exists for equipment used away from the home office — travel, co-working spaces, client meetings. Given that the laptop is the device used to access Tailscale-gated production infrastructure (see POL-07 §2), this is a real, if currently low-probability, gap: the laptop leaving the home office doesn't currently trigger any documented change in handling.

9. Storage media (7.10) — status: not_started

No storage-media handling or disposal policy exists. This is primarily relevant to the founder's laptop disk given the self-hosted-but-remote production architecture — Stratify does not expect local copies of production data to routinely exist on the laptop, but that expectation itself has not been verified or stated as policy.

10. Secure disposal or re-use of equipment (7.14) — status: not_started

No documented process exists for securely disposing of or re-provisioning retired equipment. This is relevant on a specific, foreseeable future event — laptop retirement or replacement — rather than an ongoing operational gap. Commitment: any retired laptop or storage medium that has held Stratify credentials or data should be securely wiped (or physically destroyed, if disposal rather than resale) before leaving the founder's control. No such event has occurred yet; this is stated as the standing policy for when one does.

11. Forward path

• Verify and document the three items in §5 (disk encryption, screen-lock, OS updates) as

their actual current state, not an assumption.

• Formally collect Hetzner's physical-security and compliance certifications as evidence,

via POL-05/PRO-10 (Sub-processor onboarding & review) — closing the "URGENT" flag on suppliers.yaml SUP-002, not duplicated here.

• GOV-09 (Competence, Awareness & Training Plan, pending) is where this policy's contents

should eventually be turned into something the founder (and any future hire) explicitly acknowledges, rather than a document that exists but is never actively read.

12. Related documents

• register/suppliers.yaml — SUP-002 (Hetzner Online GmbH), the supplier relationship §2

and §3 delegate physical security to

• POL-05 — Supplier & Cloud Security Policy (pending per PLAN.md §4) — where Hetzner's

certifications should be formally tracked as evidence

• PRO-10 — Sub-processor onboarding & review (pending)
• register/risks.yaml — RISK-001 (Hetzner not yet reflected in dsgvo-data-flow.md's

processor table)

• POL-07 — Operations & Change Management Policy — the Tailscale-only access model the

laptop connects through