Skip to content

External Access to the ISMS (auditors, customers, prospects)

Purpose. Defines who outside Soon may read the ISMS, how much of it, and for how long — so we can satisfy auditors and enterprise buyers without handing out material that would harm us if it leaked. Supports 7.5.3 (control of documented information / distribution), A.5.12–A.5.14 (classification, labelling, transfer) and A.5.15 (access control).

Status: DRAFT. The access tiers are defined; the Trust Center content (trust/index.md) is drafted but not yet published — that is an owner decision (§4).

1. The core rule

The ISMS is not one shareable thing. It contains, side by side:

  • material that helps us commercially (policies, architecture, certifications), and
  • material that would harm us if it leaked — the risk register naming live vulnerabilities, open questions, incident records, and internal decision notes.

Worked example (real, now resolved). Between 2026-07 and 2026-08-19 the risk register and System Description recorded that the production database was reachable from the internet (S-299 — closed 2026-08-19). Publishing the ISMS wholesale would hand an attacker a current, prioritised target list. This is exactly the material an auditor must see and a prospect must not.

Therefore access is granted by tier, never as "read the ISMS".

2. The three tiers

Tier Who Gets Mechanism
T1 — Trust Center Prospects, customers, anyone Curated, safe-to-share summary: what Soon is, certification status, security posture, sub-processors, how to report a vulnerability. No risks, no findings, no internals. Written to an external reader. Public page (or gated by email) — trust/
T2 — Documents on request Customers under NDA, security reviewers, procurement Specific approved documents (e.g. Security Overview, a named policy, the SOC 2 report once issued) — sent as PDF, watermarked where sensitive. Orientation for this audience: For security reviewers. Email/Drive link, logged in §5
T3 — Full read access Auditors and assessors only (GetAgency and its assessment partners, ISO certification body, Andrea's internal audit) Read-only access to the whole ISMS site — policies, risks, findings and the captured evidence artefacts, which are published on the site's Evidence page rather than sent as a folder (decided 2026-08-23). Orientation: For auditors and assessors. Cloudflare Access, time-boxed, logged

Never shared with anyone outside Soon, at any tier: credentials and secrets, customer personal data, and unredacted incident records.

Evidence artefacts are the exception, and only at T3. Auditors need them, so they are published on the site's Evidence page and covered by the same time-boxed login. This works only because artefacts are redacted before capture — no secrets, no customer personal data — per Evidence Collection & Management §3. Nothing is emailed, zipped or handed over as a folder: access is granted, used, and revoked.

3. Granting T3 (auditor) access — the procedure

Auditors need the uncomfortable material; that is the job. Give it deliberately, time-boxed, and revoke it when done.

  1. Confirm the engagement and confidentiality. An NDA or the engagement letter must be in place before access. Record it.
  2. Grant read-only via Cloudflare Access for the auditor's named email address — never a shared login, never a repo collaborator seat (the repo allows writes; the site does not). See the exact steps in §3.1.
  3. Send them the orientation: For auditors and assessors.
  4. Time-box it. Set an expiry matching the engagement (default 30 days, extend deliberately). Diarise the revocation.
  5. Record the grant in §5 below and screenshot the Access policy — that screenshot is evidence for the access-control and documented-information controls.
  6. Revoke on completion and record the date. Verify by checking the Access policy.
  7. Review all external access every quarter alongside the internal access review.

Cloudflare Access logs every login, so "who read the ISMS and when" is answerable — a point worth making to the auditor, as it demonstrates the access control working.

3.1 Cloudflare Access — exact steps (grant, then revoke)

The site is Cloudflare Pages behind Cloudflare Access (Zero Trust). To add an external reviewer without touching the team's own access, give them their own policy on the existing isms.soon.works application.

Grant (Cloudflare dashboard → Zero Trust → Access → Applications):

  1. Open the isms.soon.works application → Policies → Add a policy.
  2. Name it descriptively, e.g. Auditor — GetAgency — expires 2026-09-15.
  3. Action: Allow. Session duration: 24 hours (forces frequent re-auth).
  4. Include → Emails → the auditor's exact address(es) only (e.g. the GetAgency assessor). Do not use "Emails ending in @…".
  5. Require → Purpose Justification (optional) and keep the login method as one-time PIN by email, so the auditor needs no Soon account.
  6. Save. Send them https://isms.soon.works and the orientation link.

Expiry: Cloudflare policies have no built-in end date, so the expiry is operational — put the revoke date in the policy name and diarise it. (If you use Cloudflare's API/ Terraform, you can automate removal.)

Revoke (on completion, or at expiry):

  1. Same application → Policies → delete the Auditor — … policy.
  2. Zero Trust → Access → Sessions (or the user's session) → revoke any active session so it ends immediately, not just at next login.
  3. Record the revocation date in §5 and screenshot the policy list (now without the auditor).

Verification & evidence: Zero Trust → Logs → Access shows every login (who, when, which app). Export or screenshot the relevant window as the evidence artefact for this control.

4. Publishing the Trust Center (T1) — owner decision

A Trust Center shortens enterprise security reviews considerably: prospects self-serve instead of sending a questionnaire. The draft lives at trust/index.md.

Before it is published, the owner must confirm:

  • Every claim is true today — no aspirational statements (this is the failure mode that produced the incorrect "MFA enforced" / "restrictive security groups" claims in the Security Overview).
  • It names no specific vulnerability, finding, risk ID, or internal hostname.
  • Certification status is stated honestly: "SOC 2 Type 1 examination in progress; ISO 27001 certification in progress" — never "SOC 2 certified" before the report exists.
  • Where it is published (soon.works/trust or trust.soon.works) and whether it is public or email-gated.
  • It is reviewed at the same cadence as the Security Overview, and after any material change.

Decided 2026-08-13: published publicly at https://soon.works/trust (no email gate), so prospects and their security reviewers can self-serve. It lives in the marketing site (SoonHQ/homesoon) rather than the ISMS site, which keeps a hard separation: no Cloudflare Access misconfiguration on isms.soon.works can ever expose the ISMS.

5. External access register

Every grant, so the auditor can see access is controlled — and so nothing is left open.

Granted Who / org Tier Scope Expires Revoked Basis
— (no external access granted yet) — — — — —

Add a row before access is granted; fill "Revoked" the day it ends.

6. Roles

  • ISM (Olaf) — approves and grants all external access, maintains §5, runs the quarterly review, owns the Trust Center content.
  • Platform (Thomas) — administers Cloudflare Access; ensures no other route exposes the ISMS.
  • Everyone — never forwards ISMS documents externally; route requests to the ISM.

Change log

Version Date Author Comments
0.1 2026-08-08 ISMS First draft — three access tiers (Trust Center / documents on request / full auditor access), the T3 grant-and-revoke procedure via time-boxed Cloudflare Access, the pre-publication checklist for the Trust Center, and the external access register.