The Cloudwrit Security Handbook,
written for people who will still be here in two years.
A ninety page account of how a document company survives its third year, told in the order a new hire should learn it. Twenty-three findings. Four critical. Thirty-one decisions recorded. One opinion about backups we feel strongly about.
Sanitized sample · Not a real engagementChapter 01 The story so far, in one page.
Cloudwrit is three years old, forty-two people, and stores roughly 1.4 million documents for 8,900 paying customers. You have been hit with one credential stuffing campaign (resolved), one GDPR inquiry (resolved), and a scare involving a leaked AWS access key (resolved faster than most firms manage, a detail we will return to). On balance, this is a healthy security posture for the stage, run by two people, and it will not scale to the position you plan to be in by the end of 2026.
The thesis of this handbook is simple. You are past the point where ad hoc security works, and well before the point where a CISO and team of twelve makes sense. Everything that follows is written to land you cleanly in that middle space, where a small team plus a handful of opinionated automations handles eighty percent of what a much larger security org handles, and where the other twenty percent is scoped well enough that bringing in specialists (us, or others) is a budget line rather than a scramble.
We wrote this with three readers in mind. Maya, who will run security day to day. Ben, who will approve the budget. And the person you will hire in nine months, who needs to understand what decisions were made and why, without interviewing everyone still here. If this handbook fails any of them, we want to know.
Chapter 02 Four things to fix this quarter.
We ran a ten day engagement across your production AWS organization, your identity provider, your CI pipelines, and a representative slice of your customer facing application. Twenty-three findings. Four we believe require action inside this quarter. The rest are scheduled in chapter six.
Document preview service runs with over-broad IAM role
The preview worker assumes a role that grants s3:GetObject across the entire document bucket, rather than scoped to the tenant prefix. A SSRF or path traversal in the preview renderer would give access to every customer document. We wrote and tested a proof of concept. See Appendix A.2.
Session cookies lack rotation on privilege change
When a user is promoted to workspace admin, their existing session retains the old claims until it expires (30 days). Abuse path: a shared device, a recently demoted employee, or a stolen cookie retains admin for weeks.
Webhook signing secret reuse across environments
The same HMAC secret is used in staging and production. A staging leak compromises production webhook authenticity. Rotation plan drafted in chapter 6.
No alerting on IAM policy drift in production accounts
AWS Config is on, but the rules are aspirational, not alerting. A developer with AdministratorAccess can widen any policy without anyone knowing for up to 24 hours. We saw this happen during week one of the engagement, on a test account.
The pattern across these four is not unusual for your size, and it is not a verdict on anyone. Two of them are consequences of a sensible decision made in 2023 that has not been revisited. The other two are the kind of thing that shows up when a team doubles in size and the original authors stop being the only ones touching the code. All four are in chapter six with sequenced work.
Chapter 03 Findings, with evidence and repro steps.
The full chapter reproduces all twenty-three findings in the format above, with proof of exploit where we have one, affected assets, remediation sequenced by blast radius, and a field for your engineer to initial once it is closed. We include the transcripts of Claude's reasoning for each finding, so you can see the analytical chain rather than just the conclusion. This is the chapter your auditors will want, and the chapter your engineers will read.
A small sample of what that looks like in practice follows. The full chapter is omitted from the sample.
Chapter 04 How your auth system actually works.
Three people in your company can draw this accurately. After this chapter, fifteen people can. That matters because your most expensive outage last year (November, 40 minutes, postmortem not written) was rooted in someone modifying a part of the auth system they did not realize had downstream consumers. The chapter is twenty-two pages and reads in order.
- The boundaries: what the identity service owns, what it does not, and why the split was made in 2024.
- The five trust paths a request can take, with a walkthrough of each and its failure modes.
- The four known sharp edges, and the reasoning for leaving each in place for now.
- The three pieces of legacy that are load-bearing and not yet written down elsewhere.
- Where we believe the system should be in 12 months, and why not sooner.
Chapter 06 The six month roadmap, sequenced.
Everything in the handbook resolves to this chapter. Twenty-three findings plus four structural initiatives, ordered by when they should happen, assuming you keep security staffing flat for the next two quarters and raise it to three people in Q3. Every line has an owner field, an estimate, a definition of done, and a reviewer other than the owner. If we have done our job, this chapter survives contact with your sprint planning without modification.
The remaining pages continue in this register: plain, sequenced, specific. There is a chapter on detection engineering you can use the morning you receive this, an appendix of Claude's reasoning transcripts so your team can audit or disagree, and a decision log that starts today and keeps a running record of every security choice you make for as long as this handbook is live.