iso 27001 as a 5-person startup

5-person team going through ISO 27001 certification while simultaneously building the product. The audit surfaces every shortcut you’ve taken and forces you to decide which ones you can defend.

Having security controls and proving you have security controls are completely different skills. We had logging. We had access controls. We had encryption. What we didn’t have was organized evidence that any of it existed.

The BYOD question hit us early. Everyone uses their own devices. The auditor wants a BYOD policy covering device registration, security requirements, acceptable use, and offboarding. Plus technical controls: MDM, application whitelisting, containerization, remote wipe. For a 5-person team where everyone’s a developer. The policy document took longer to write than most of our features.

Then came control C.14: “Log files created for security events.” Our colleague flagged the blocker:

I’m blocked because I don’t have access to Azure, DigitalOcean, Sentry, or GitHub. I can only do the Tally Form logs for now.

The auditor doesn’t need comprehensive SIEM output. They need evidence that logging exists and is configured. Screenshots of logging configs in DigitalOcean, sample security event logs from Sentry, audit log settings from GitHub. Quick wins, but someone needs access to each platform, and in a small team, access is concentrated.

Risk assessments are actually useful. Expected bureaucratic theater. Instead they forced us to document BYOD risks, show mitigating controls, and make explicit risk acceptance decisions. That document became genuinely useful for onboarding.

The backup retention question matters. Our auditor asked about personal data in DigitalOcean backups. Managed databases back up daily with 7-day retention. When you delete data from the main database, it persists in backups for up to 7 days. Can’t selectively delete from backups. For GDPR, deleted personal data might still be recoverable for a week. Had to document this as an accepted risk with justification.

Compliance compounds with product decisions. We were already building ECHO with GitOps, infrastructure-as-code, and self-hosted LLM configs. Those architectural decisions, made for engineering reasons, turned out to be compliance assets. Reproducible infrastructure means you can demonstrate consistent security configurations across environments.

Start documenting before you need to. The worst part of audit prep isn’t implementing controls, it’s retroactively proving you had them. A security/ folder in your repo with dated policy documents and config screenshots is worth more than you think.

Concentrate access thoughtfully. When one person holds the keys to Azure, DO, Sentry, and GitHub, they become a bottleneck during evidence collection. Spread access or at least document the access matrix early.

Don’t over-engineer for the audit. A 5-person startup doesn’t need enterprise SIEM. It needs to show that logging is enabled, reviewed, and someone is paying attention.

Still audit-pending as of writing. But the process already made us a better engineering team. Not because of the policies, but because writing them down forced us to think about what we do and why.