Topic
Sign in
Peyman Owladi

Charities and campaigns hold some of the most sensitive data there is – beneficiaries, members, donors, political opinions – on some of the smallest tech budgets there are. Rapid iteration and good security are usually presented as a trade-off. In my experience they can go hand in hand: get the architecture right and a tiny team can ship daily without lying awake at night – and less technical teammates can get stuck in too.

I've architected products like Learning with Parents to build for security with minimal impairment to velocity, as well as working on DPIAs for government procurement, taking organisations through Cyber Essentials and ISO 27001 certification with policies and processes designed to minimise disruption, and building an AI product (Chalk) that touches schools' data, all with a handful of people. Happy to discuss what we've done to make this work.

My first thought in designing security architecture is to contain the risk in the smallest space possible – safety nets, sensible defaults, and clear boundaries around data – so the area that needs strict verification stays small. In a tech stack this means database-level controls on data access (specifically the Postgres "Row-Level Security" feature). At the org level it can mean a single store of sensitive data with separate controls from the rest of the estate. And data privacy needs to be thought about from day one – a DPIA can be a design tool – and it's useful to know the attack categories that actually hit small orgs.

Key question/s: How much security does your project actually need, and where should it live? What would let you stop worrying about most of your codebase?

Reading/links