A startup needs five kinds of log before anything else: identity provider sign ins, cloud audit events, source control audit events, application authentication and admin actions, and email or file sharing admin logs. Send them to one place, protect them from deletion, and keep at least several months. Add volume only when a question needs it.
Start from the questions
Logs exist to answer questions after something goes wrong. Who logged in? What changed in production? Who downloaded the data? Which token was used? Pick the logs that answer those, not everything the system can emit.
The five to turn on first
- Identity provider. Sign ins, MFA events, failed attempts, new device and location, admin changes.
- Cloud audit logs. Who called which API on which resource. Make sure they cover all regions and accounts, and are on by default for new accounts.
- Source control audit log. Membership changes, new tokens, deploy keys, repository setting changes, secret scanning events.
- Application logs for authentication and administrative actions: logins, password resets, role changes, data exports, API key creation.
- Email and file sharing admin logs. Mail rules, forwarding, sharing links, third party app grants.
Where to send them
Use one searchable store, even if small. A managed log service or a simple storage bucket with a query tool will do. What matters is that you can search by user and time without logging into six consoles.
Protect the logs
An attacker will try to delete evidence. Put logs in a separate account or location with write only access from the source, and limit who can delete. Turn on integrity features offered by your cloud provider if available. Alert if logging is turned off.
Retention
There is no single right answer, since contracts and laws differ. A common starting point is to keep security relevant logs for at least several months in searchable form and longer in cheaper storage. Check any customer contract, insurer requirement or law that sets a minimum, and write the decision down.
What not to log
Do not log passwords, full tokens, card numbers or other secrets. Mask personal data where you can. Logs are data too, and a leaky log can become the breach.
Alerts worth setting.
Keep these few and send them to a shared channel: root or owner sign in, new admin created, MFA disabled, logging disabled, impossible travel on an admin, and large data export. Review them in your weekly security hour.
Test it.
Once a quarter, run a mock question: find everything one account did last Tuesday. If you cannot answer in an hour, fix the gap that blocked you.
Common pitfalls.
Common mistakes: turning logging on only for one region, forgetting new accounts and projects, and discovering after an incident that the default retention was a few days. Add a check to your new account checklist, and review log settings each quarter. Also record time zones consistently, because correlating events across systems is painful when each uses a different clock or zone.
Quick check
Do we need a SIEM?
Not at first. A central searchable store and a few alerts cover most small team needs. Add more when volume and questions grow.
Last reviewed: 19 October 2026.
