Skip to content

SOC 2 Type 1 — three-week close-out plan

Purpose. Get Soon from 26 of 68 controls done to a complete evidence pack in GetAgency's hands, by Friday 11 September 2026. Every task below names one person, one action, and the artefact it produces. Tracks corrective actions (10.2) and monitoring follow-up (9.1 / CC4.2).

Replaces v0.1, whose two-week window (10–21 August) has passed. Position is unchanged at 26 Done · 36 In progress · 2 Not started · 4 N/A — the plan slipped because it had no fixed weekly slot and no owner-by-name task list. Both are fixed here.

1. The date we are working to
Week 1 Mon 24 → Fri 28 August — the blockers and the two false claims
Week 2 Mon 31 Aug → Fri 4 September — evidence capture and the tests
Week 3 Mon 7 → Fri 11 September — paperwork, review, handover
Handover Friday 11 September — evidence pack to GetAgency (Tad), or auditor access granted

Three weeks is achievable because most of the writing is done. Of the 42 documents in the ISMS that are still draft, 29 have no open questions at all — they need reading and signing, not authoring.

2. The fixed weekly slot

Thursday 13:00–14:00 CEST — the SOC 2 working session. This is the existing standing ISMS slot; for these three weeks it is widened from Olaf + Andrea to all four founders. Dates: 27 Aug · 3 Sep · 10 Sep.

It is a working session, not a status meeting. Everyone joins with their laptop open and captures their evidence live, on the call. Screenshots taken together in an hour actually happen; screenshots assigned as homework do not — which is precisely why the previous plan slipped. Olaf runs python3 tools/evidence.py on screen so nobody has to remember the naming convention.

Monday 09:15–09:30 CEST — 15-minute check-in. What's due this week, what's blocked. Can be async in Slack #Security if everyone posts before 10:00.

(An ISMS with a documented weekly cadence and a five-week gap in the minutes is itself an audit observation — the last logged session was 24 July. Restarting the cadence is worth more than the hour it costs.)

3. What "done" means

A control is Done only when it exists and the evidence is filed. Type 1 tests a point in time, so an auditor asks: show me. The evidence store and its tooling are built (§6) — the constraint now is capture, not infrastructure.

4. Week 1 — Mon 24 to Fri 28 August

Theme: fix the two things we are currently claiming but not doing.

# Task Why it matters Owner Rows
1 Enable branch protection (or a ruleset) on main in soon-server, frontend, soon-integrations, soon-connect, soon-terraform, soon-grc: require a PR, 1 approval, and Code Owner review Verified 2026-08-22: none of the six repos has any branch protection or ruleset. Rows #61, #62 and #64 are currently marked Done, and the public Trust Center says every change is peer-reviewed. An auditor disproves all of it with one API call Thomas 61, 62, 64
2 Turn on organisation-wide 2FA in GitHub (SoonHQ → Settings → Authentication security) Verified 2026-08-22: two_factor_requirement_enabled: false. Row #34 cannot be honest until this is a setting rather than an expectation Thomas 34
3 Set sendDefaultPii: false in soon-server/src/instrument.js:19 and enable Sentry server-side scrubbing; confirm the Sentry project's data region Verified 2026-08-22: Sentry is configured to send PII and beforeSend does no scrubbing. This is a live GDPR exposure, not just a paperwork gap Thomas 36, 42
4 ✅ DONE 2026-08-19 — dsync Lambda attached to the VPC (S-371) Was the blocker for task 5 Thomas —
5 ✅ DONE 2026-08-19 — public database endpoint removed (soon-server#1675). Now: capture the evidence — export PubliclyAccessible: false and the security-group rules — and finish the legacy security-group cleanup Was the single biggest exposure. Until the export exists we can assert it but not show it, and CC6.6 turns on being able to show it Thomas 44, 45
6 Approve the ready policy set — 29 documents with no open questions Converts more checklist rows than any other single hour. The list, with a link per document, is in APPROVAL-BATCH.md at the repo root Olaf ~15 rows
7 aws login, then python3 tools/evidence.py check and file the first three artefacts Proves the evidence pipeline end-to-end before the team depends on it Olaf 46
8 Revoke the unused DeepSeek / Mistral / xAI API keys in production Live credentials for services we do not use Thomas 49
9 Org chart with the security owner marked, plus one-paragraph job descriptions for the four founders Two rows, one hour, no dependencies Alessandro 8, 10
10 Collect the signed NDAs / contractor agreements for all four founders and Andrea into Drive → Legal #2, #3 and #4 are all waiting on the same folder Alessandro 2, 3, 4
11 Connect AWS Chatbot → Slack #Security (the SNS topic is already live) Completes the alerting path for #55 Olaf 55
12 Run the restore test: restore the latest rds-soon-soon-prod snapshot to a throwaway instance, verify a known row, record the timings, delete it The single most-cited SOC 2 gap. Auditors always ask, and "PITR is enabled" is not an answer Melvin 60

5. Week 2 — Mon 31 August to Fri 4 September

Theme: capture the evidence and run the two tests.

# Task Why it matters Owner Rows
13 Evidence capture sprint — every screenshot in the Evidence Register, captured in the Thursday session The bulk of the remaining work is capture, not decision All many
14 IR + DR tabletop, 90 minutes, minuted — one incident scenario and one disaster scenario, run after S-299 closes so it reflects the audited environment Evidences two rows in one sitting, and both are currently Not started Olaf + Thomas 59, 66
15 Write the BC/DR plan — targets are already set (99.5% uptime, RTO 8h, RPO 24h); the tabletop supplies the content Currently missing entirely Olaf/Melvin 65
16 First quarterly access review — AWS IAM, GitHub, Google Workspace, WorkOS. Export the user lists, mark each row keep/remove, sign and file Never performed; #39 needs the record, not the policy Thomas 38, 39
17 Isolated backup copy — AWS Backup vault in the log-archive account plus a copy to eu-central-1 (~€25/month at 120 GB) Today one account compromise destroys the database and every snapshot Melvin 60
18 Security awareness training round — all four founders + Andrea run /isms:onboard; the log is currently empty #14 and #18 both read from that log Alessandro to schedule, all to complete 14, 18
19 Collect vendor DPAs and SOC 2 reports for the 12 Category A sub-processors into Drive → Legal → Vendors The register already lists exactly which ones Alessandro 67, 68
20 Device attestation round — each founder completes the Device Security Standard checklist and screenshots FileVault, firewall, lock timer and OS version Makes the no-MDM position evidenced rather than asserted Alessandro to run, all to complete 40, 50
21 Network diagram — VPC, subnets, security groups, the data path. Draw it from soon-terraform/modules/network #45 needs a picture; the auditor will also use it to frame questions Thomas 45
22 Push the corrected sub-processor list live to soon.works/trust The published list currently omits PostHog, OpenAI, Cloudinary, SES and Maps Olaf 18

6. Week 3 — Mon 7 to Fri 11 September

Theme: close the remaining decisions, review, hand over.

# Task Why it matters Owner Rows
23 Settle the remaining owner decisions — vulnerability SLAs, patch windows, background-check policy, retention periods with the accountant Twelve documents are one or two answers away from approvable Olaf many
24 Approve the second wave of policies once §23 lands Converts the last of the "In progress" rows Olaf many
25 Enable secret scanning + push protection on the six repos (confirm whether the Team plan needs the paid add-on; Aikido may already cover this) #51 and #63; if Aikido covers it, record that instead and save the money Thomas 51, 63
26 Annual firewall / security-group review — walk every rule, delete the legacy groups listed in the S-299 runbook step 5, sign the record #46 needs a performed review Thomas 46
27 Pre-audit walkthrough with Andrea — independent review of the full checklist Also evidences internal audit (#28) and it is better that Andrea finds the gaps than Tad Olaf + Andrea 28, 29
28 Assemble and hand over the pack (§8) The deliverable Olaf —
29 Schedule the GetAgency pentest for after S-299 closes Included at no cost (confirmed 2026-08-11); longest external lead time, so chase the date in week 1 even though the test runs later Olaf 52

7. Who does what — the short version

Thomas — six technical items, front-loaded: branch protection, org 2FA, Sentry PII, the S-299 evidence capture, access review, network diagram, firewall review. Tasks 1, 2 and 3 are the urgent ones: all three are gaps between what we claim and what is configured.

Alessandro — the paperwork and people track, none of which needs AWS: org chart and job descriptions, NDAs and contracts, vendor DPAs, training round, device attestation round. This is roughly a day and a half of work spread over three weeks, and it unblocks nine checklist rows that nobody else is going to do.

Melvin — two infrastructure items: the restore test (week 1) and the isolated backup vault (week 2).

Olaf — approvals, the two tabletops, the BC/DR plan, the owner decisions, the Trust Center fix, and the handover. Plus running the Thursday session.

Andrea — the week 3 independent walkthrough.

8. How evidence gets captured

The store is live: s3://soon-isms-evidence in the log-archive account 404379474355, Object Lock 3 years. The tooling now exists — tools/evidence.py — so a capture is one command:

python3 tools/evidence.py shot --control A.5.17 --desc mfa-enforced-github --soc2 34 --cc CC6.1

That stamps a visible UTC timestamp onto the image, hashes it, uploads it under both our naming convention and GetAgency's CC6/34-… folder layout, and logs it with its SHA-256.

Do this once on each machine so full-screen captures carry their own clock:

python3 tools/evidence.py clock

Full rules: Evidence Collection & Management §5.

9. The handover pack (Friday 11 September)

  1. The filled GetAgency checklist — every row Done or explained.
  2. The System Description — a required Type 1 deliverable.
  3. A time-boxed, named login to isms.soon.works — this is the handover mechanism. Tad and the auditors read the approved policy set and the captured evidence in one place, on the site's Evidence page, with each artefact's capture time, capturer and SHA-256 beside it. We do not send a folder (decided 2026-08-23): a zip starts ageing the moment it is made, and it splits the policies from the proof. Granted and revoked per External Access §3.
  4. The Vendor & Sub-processor Register and the collected DPAs.

10. What a Type 1 needs that the 68-row checklist does not ask for

GetAgency's checklist covers the controls. It does not cover the report mechanics, and three of these are hard blockers — they were found in an independent pre-audit review on 2026-08-22 and none of them appears anywhere in the ISMS today.

Gap Why it blocks the report Owner
No Management Assertion Section I of a Type 1 report is management's written assertion, signed by the responsible officer. Verified missing: nothing in the repo mentions one. Without it there is no report to issue Olaf
Trust Services Categories not chosen Security only, or Security + Availability + Confidentiality? The decision changes the criteria set, the System Description and roughly a third of the evidence. Confirm with Tad before capture starts, because the Security Overview already promises availability and confidentiality to customers Olaf
No as-of date chosen Type 1 tests design and implementation as of one date. Approving 30 policies in one batch and dating the report a week later is not credible design evidence — git history shows exactly when everything landed. Set the date a few weeks after the last first-execution, realistically late September, and say plainly in the description that the ISMS was established in 2026 and this is the first period Olaf
Carve-out method not stated The System Description has complementary user entity controls (§8) but never names the subservice organisations (AWS, Cloudflare, WorkOS, Stripe, Google) or states that they are carved out. Also read their SOC 2 reports and record a dated review Olaf
No Article 30(2) record The Privacy Policy says a RoPA exists but its location is still TODO. As a processor with 12 sub-processors this is a statutory obligation, not a nice-to-have — and enterprise buyers ask for it Olaf
US transfer mechanisms not recorded Intercom, OpenAI, Sentry, Stripe, Cloudinary and Google all involve transfers. Each needs its mechanism recorded (Data Privacy Framework certification with the date checked, or SCC module) and a short transfer impact assessment for the ones carrying identifiable data Olaf

Two further points worth deciding rather than drifting into:

  • The public database is closed — now prove it. The endpoint was removed on 2026-08-19, which takes the qualified-opinion risk off the table. What remains is evidential: a control an auditor cannot see tested is a control they treat as absent, so the PubliclyAccessible: false export and the security-group rules are among the first artefacts to capture. Worth stating the closure date in the description too — a limitation fixed a month before the as-of date reads very differently from one fixed the week before.
  • Ask Tad about the pentest arrangement in writing. If GetAgency performs the penetration test and audits whether the pentest control is suitably designed, that is a self-review threat under AICPA independence rules. Almost certainly they use a separate team — but get the confirmation on record rather than discovering it late.

Also worth a documented position: internal audit independence. Andrea is a paid contractor and the brother of a founder who owns controls, while Olaf authors, approves and self-assesses most of the ISMS. That is normal for a four-person company and it is not disqualifying — but it must be written down with its compensating controls, not left for an auditor to notice unaided.

11. Risks to this plan

  • The tasks 4/5 chain has cleared (both landed 2026-08-19), which unblocks the tabletop (14) and the pentest (29) — both were deliberately sequenced behind it. Neither has an excuse to wait now.
  • Nothing is assigned to Alessandro today. Tasks 9, 10, 18, 19 and 20 are new to him; they are deliberately self-contained and need no context from the rest of the ISMS.
  • The pentest is external. It is confirmed and free, but GetAgency's calendar is not ours. Chase the date in week 1 even though the test itself lands later.
  • Honesty beats completeness. A row marked In progress with a dated remediation plan reads far better than a row marked Done that an auditor disproves — which is exactly the risk that tasks 1 and 2 exist to remove.

Progress

Date Done In progress Not started N/A
2026-08-08 (baseline) 26 36 2 4
2026-08-22 (re-plan) 26 36 2 4

Appendix A — every open control, verified

All 38 rows still open on GetAgency's checklist, each checked against the repo and then re-checked by an independent reviewer on 2026-08-22. Est. is realistic effort, not optimistic effort — the totals are the point of the table.

# CC Control What actually closes it Evidence artefact Owner Est.
1 CC1.1 Code of conduct & disciplinary policy Resolve all SIX open TODO items in the HR Security Policy — the three body items (VOG practice, applicable labour law, and the alternate whistleblowing recipient, which must be a second… 1-CC1.1-conduct-policies-approved-plus-five-acknowledgements.p… Olaf 2.5h
2 CC1.1 Confidentiality agreements (NDAs) Do NOT have the four founders sign the existing NDA template — it is a one-way Discloser/Recipient third-party NDA with unfilled brackets and is nonsense between a company and its own… 2-CC1.1-founder-confidentiality-undertakings-and-cybersquad-nd… Alessandro 2.0h
3 CC1.1 Employment agreements Write down each founder's actual construct (DGA management agreement vs employment contract vs ZZP), set the single survival-period number that unblocks ISMS-DOC-A06-2-1's two TODOs,… 3-CC1.1-founder-employment-agreements-redacted.pdf Olaf 4.0h
4 CC1.1 Contractor agreements Confirm whether a signed CyberSquad consultancy agreement already exists; if not, draft a one-page consultancy agreement from scratch (no contractor-agreement template exists in the repo —… 4-CC1.1-cybersquad-contractor-agreement-signed.pdf Olaf 3.0h
5 CC1.2 Board / leadership oversight of security Hold one ISMS session with all FOUR founders present at the standing Thursday 13:00 CEST slot on 2026-08-27 (verified a Thursday), minute it in docs/09-performance/meeting-log/ with date,… 5-CC1.2-leadership-security-review-minutes-2026-08-27.pdf Olaf 2.0h
8 CC1.3 Org chart & defined reporting lines After row 10 adds role definitions for Melvin and Alessandro to ISMS-DOC-05-2, draw a one-page org chart showing the four founders with their actual functions and reporting lines, Olaf… 8-CC1.3-org-chart-security-owner-labelled.png Alessandro 45m
10 CC1.4 Job descriptions & competence Add §1.x role definitions to ISMS-DOC-05-2 for Melvin Jacobson (infrastructure/IaC, backups, cloud configuration) and Alessandro Cardinali (product, customer-facing security commitments)… 10-CC1.4-role-security-responsibilities-raci.pdf Olaf 2.0h
11 CC1.4 Background checks Stamp the TODO-free Employee Screening Checklist with python3 tools/approve.py --stamp ISMS-FORM-A06-1-1, resolve the VOG TODO in HR Security Policy §2.1, and sign a dated management… 11-CC1.4-screening-procedure-and-no-completed-checks-attestati… Olaf 60m
13 CC2.1 Information Security Policy Decide the three body open TODO items in the Information Security Policy (target certification date line 46, ISO 27017/27018 ambition line 73, leadership statement line 140) AND the two… 13-CC2.1-information-security-policy-approved.pdf Olaf 60m
14 CC2.2 Security awareness training Have all four founders and Andrea each run /isms:onboard against ESSENTIALS.md so five dated, named rows with material version and git SHA replace the single placeholder row in the… 14-CC2.2-security-training-log-and-essentials.pdf Olaf 1.5h
24 CC3.1 CC3.1 — Defined business & security objectives Answer the six open TODO items (top management = the four founders; Andrea's engagement scope; tooling/training/certification budget; POST25 follow-up status; ISO certification body —… 24-CC3.1-security-objectives-approved.pdf Olaf 1.5h
25 CC3.2 CC3.2 — Annual risk assessment Do NOT delete the 2026-07-04 change-log row (that is the audit trail) — instead correct the line-100 footnote in place with a dated 'superseded 2026-08-13' correction, recount and fix the… 25-CC3.2-risk-assessment-report-approved.pdf Olaf 2.5h
28 CC4.1 CC4.1 — Periodic control self-assessment Correct the stale backup facts in ISMS-FORM-09-7 (PITR is on, retention 30 days, Multi-AZ) and expand it from a summary into the actual per-control assessment by pulling the 68 rows out of… 28-CC4.1-control-self-assessment-signed.pdf Olaf 3.0h
29 CC4.2 CC4.2 — Track and remediate deficiencies Create docs/10-improvement/ISMS-FORM-10-1-nonconformity-and-corrective-action-log.md with exactly the twelve columns ISMS-DOC-10-1 §3 names, seed it with the four deficiencies Soon… 29-CC4.2-capa-log-open-findings.pdf Olaf 1.5h
32 CC5.3 CC5.3 — Policies enacted through procedures Sequence this AFTER the row-36 classification decision and the approval batch: export REGISTER.md (which already shows doc_id, type, status, version, owner and next-review date for all 84… 32-CC5.3-approved-policy-set-responsibilities-review-frequency… Alessandro 45m
33 CC6.1 CC6.1 — Access control policy & least… Have Thomas confirm WorkOS as the IdP and list the systems not behind SSO, delete the GCP Secret Manager and 'AWS, GCP, Azure' references in ISMS-DOC-A05-18-1 §5/§7 (Soon is AWS eu-west-1… 33-CC6.1-access-control-policy-and-access-matrix.pdf Thomas 4.0h
34 CC6.1 CC6.1 — MFA on all critical systems Audit every SoonHQ GitHub org member, machine account and outside collaborator for 2FA enrolment first (turning the org setting on removes anyone unenrolled and can break CI), then enable… 34-CC6.1-mfa-enforced-github.png Thomas 1.5h
36 CC6.1 CC6.1 — Data classification policy Decide explicitly whether 'Protected' becomes a declared fifth level (cheapest — no approved document is disturbed) or the 11 documents are relabelled onto the four-level scheme (then… 36-CC6.1-information-classification-policy-approved.pdf Olaf 2.5h
38 CC6.2 Access provisioning on hire (CC6.2) Create the missing New Starter / Access Provisioning Checklist form, add the role-based baseline access profiles the process promises (AWS, GitHub, Google Workspace, WorkOS, Linear, Enpass… 38-CC6.2-access-provisioning-checklist-and-role-baseline.pdf Olaf 1.5h
39 CC6.3 Access removal on departure & quarterly… Run the first quarterly access review — export user/role lists from AWS IAM, GitHub org, Google Workspace and WorkOS, mark every account keep/remove with a reason, resolve Andrea's… 39-CC6.3-q3-2026-access-review-signed.pdf Thomas 2.0h
40 CC6.4 Physical access / office & devices (CC6.4) Write and approve a one-page Physical & Environmental Security Statement (no offices, no data centres, no company hardware, all endpoints BYOD, home-working controls) citing the system… 40-CC6.4-physical-security-statement-no-premises.pdf Olaf 45m
41 CC6.5 Secure disposal of data & devices (CC6.5) Add a 'Secure disposal and re-use' section to the Device Security Standard covering BYOD (owner-executed wipe, Soon account/token/Enpass removal, written confirmation on the Termination… 41-CC6.5-secure-disposal-standard.pdf Olaf 45m
42 CC6.5 Data retention & disposal procedures (CC6.5) Fill the three open retention rows with per-type NL periods rather than a blanket figure — financial/accounting and payroll-tax records 7 years, personnel-file records ~2 years after… 42-CC6.5-records-retention-policy-approved.pdf Olaf 45m
43 CC6.5 Customer data deletion on departure (CC6.5) Verify the standard DPA quotes the same 90-day period (Olaf's open TODO), check Stripe cancellations / Attio / Linear for customers that actually offboarded in the last 12 months and… 43-CC6.5-customer-data-deletion-procedure-and-record.pdf Olaf 60m
45 CC6.6 Network segmentation & diagram (CC6.6) Draw the production VPC diagram (Cloudflare edge, public/private subnets, ALB, ECS/Fargate, RDS, dsync Lambda, dev/staging) as Mermaid inside the Cloud & Infrastructure Security Policy; in… 45-CC6.6-production-network-diagram.png Thomas 2.0h
46 CC6.6 Annual firewall rule review (CC6.6) Export every security group across all VPCs with aws ec2 describe-security-groups --region eu-west-1, plus aws rds describe-db-instances for PubliclyAccessible, review each rule against… 46-CC6.6-security-group-rule-review-2026.pdf Thomas 75m
49 CC6.7 Encryption key management (CC6.7) Confirm first whether any customer-managed KMS keys exist in eu-west-1: if so screenshot the key list, one key policy and the rotation setting; if only AWS-managed keys are in use, capture… 49-CC6.7-kms-key-policy-and-rotation.png Thomas 75m
52 CC7.1 Annual penetration test (CC7.1) Email Tad at GetAgency to book the already-included penetration test, agree scope and rules of engagement in writing with a provisional date contingent on S-299 closing, file the signed… 52-CC7.1-pentest-scope-agreement-getagency.pdf Olaf 45m
53 CC7.1 Hardening standards (CC7.1) Rewrite the Configuration Management Policy around the baselines Soon actually applies — Terraform (soon-terraform) as the configuration of record with PR review, pinned container base… 53-CC7.1-hardening-standard-approved.pdf Thomas 1.5h
57 CC7.3 Security incidents evaluated (CC7.3) Create the security label in the Soon Linear team (verified 2026-08-22: no such label exists), apply it to the open security findings already tracked there (S-299 public RDS, S-357 solver… 57-CC7.3-incident-log-linear.png Olaf 45m
58 CC7.4 Incident response plan (CC7.4) Answer the two open TODO items in ISMS-DOC-A05-34-2 (actual notification timelines read out of the signed customer DPAs, not assumed; breach-register location and owner), replace the §7… 58-CC7.4-incident-response-plan-approved.pdf Olaf 1.5h
59 CC7.4 Annual incident response test (CC7.4) Put a fixed 90-minute IR+DR tabletop date in the calendar for Olaf and Thomas this coming week and either assign Linear S-371 to a named person with a due date or formally overturn the… 59-CC7.4-ir-tabletop-writeup.pdf Olaf 1.5h
60 CC7.5 Recovery from incidents — backups & restore… Assign Linear S-327 to Melvin with a date, restore the latest rds-soon-soon-prod snapshot into a throwaway instance in eu-west-1 explicitly attached to a private security group and with… 60-CC7.5-rds-restore-test.pdf Melvin 3.0h
63 CC8.1 SDLC policy (CC8.1) Have Thomas answer the four open TODO markers in ISMS-DOC-A08-25-1 (dependency scanning — Aikido is already confirmed in use per the vendor register line 107; GitHub code and secret… 63-CC8.1-secure-development-policy-approved.pdf Thomas 1.5h
65 CC9.1 Business continuity / disaster recovery plan… Write ISMS-DOC-A05-30-4 as a two-page ICT Continuity & Disaster Recovery Plan covering A.5.29 and A.5.30 — scenarios (AZ or instance loss, AWS account compromise, key-person loss), the RTO… 65-CC9.1-bcdr-plan-approved.pdf Olaf 3.0h
66 CC9.1 Tabletop disaster recovery test, annual… Add a second scenario to the same session — total loss of the eu-west-1 RDS instance, walked against the restore runbook produced by #60 rather than against an unwritten procedure — and… 66-CC9.1-dr-tabletop-writeup.pdf Olaf 45m
67 CC9.2 Vendor management & review (CC9.2) Add "Last reviewed / Next review" columns to BOTH the Category A table and the Critical and Important rows of the Category C table in ISMS-FORM-A05-19-1, add a dated review-log entry in §8… 67-CC9.2-vendor-register-approved.pdf Olaf 1.5h
68 CC9.2 Vendor agreements with confidentiality terms… Download the publicly available AWS GDPR Data Processing Addendum plus the Cloudflare and Stripe DPAs, file all three in Drive → Legal → Vendors, capture the page carrying AWS's… 68-CC9.2-aws-dpa-confidentiality.pdf Alessandro 60m

Where the work actually sits

Owner Controls Effort
Olaf 25 42.5h
Thomas 8 15.0h
Alessandro 4 4.5h
Melvin 1 3.0h
38 65.0h

The bottleneck is Olaf, and naming it is the point. Two-thirds of the open controls and roughly 40 hours sit with one person who is also running the sessions, chasing Tad and writing the BC/DR plan. Three weeks does not contain that alongside a day job.

Two ways out, and it needs one of them: move the documentation-shaped rows to Alessandro (he currently holds 4 controls and about 4 hours — there is room), or cut scope to Security only and defer anything the chosen Trust Services Categories do not require. Deciding the TSC scope (§10) shrinks this table before anyone touches it, which is why that decision comes first rather than last.

Change log

Version Date Author Comments
0.4 2026-08-22 ISMS Added Appendix A — all 38 open controls verified against the repo with the minimum action, evidence artefact, owner and realistic effort for each. Surfaces the real constraint: 25 of 38 controls and ~42 hours sit with Olaf.
0.3 2026-08-22 ISMS Added §10 — the Type 1 report mechanics the 68-row checklist does not cover: missing Management Assertion, undecided Trust Services Categories, no as-of date, carve-out method unstated, no Article 30(2) record, US transfer mechanisms unrecorded. From an independent pre-audit review.
0.2 2026-08-22 ISMS Re-planned as three weeks (24 Aug → 11 Sep) after v0.1's window passed. Added the fixed Thursday 13:00 CEST working session and Monday check-in; per-person task lists including Alessandro; three newly verified gaps (no branch protection on any repo, GitHub org 2FA off, Sentry sendDefaultPii: true); the evidence-capture tooling; and the handover pack.
0.1 2026-08-08 ISMS First draft — 20 tasks across two weeks (10–14 Aug, 17–21 Aug) with owners, the checklist rows each closes, dependencies, and the pre-examination steps.