Logging and monitoring for SOC 2
By Sam Rivera, Founder, SentinelPanda · June 19, 2026 · 1 min read · SOC 2
Collecting logs is the easy half. SOC 2 wants evidence that someone notices when they say something — alerts that fire and get actioned.
What the control covers
The Common Criteria expect you to monitor your systems to detect security events and respond to them. In practice that is three things: collecting logs, alerting on the meaningful ones, and demonstrating that someone investigates the alerts. Logs nobody watches do not satisfy the control.
What to log
- Authentication events — successes, failures, MFA challenges, and lockouts.
- Authorisation changes — new admins, role changes, privilege grants.
- Infrastructure and application events relevant to security, plus access to sensitive data where feasible.
Protect and retain
Logs that an attacker (or a careless admin) can edit are not trustworthy evidence — centralise them somewhere append-only or access-restricted. Set a retention period that matches your needs and any regulatory obligation, and apply it consistently. Auditors check both that you keep enough and that you do not keep sensitive data forever.
Prove you respond
The part teams skip is evidence of response: an alert fired, someone triaged it, and there is a record. A monitoring stack that generates alerts into a void is a finding waiting to happen. Keep the alert-to-action trail — that is what turns "we have logging" into "we have monitoring." SentinelPanda tracks the monitoring control and stores the response evidence.