Logging and monitoring controls for SOC 2

Why this matters

SOC 2 tests whether controls are designed well. A Type II report also tests whether they operated over the period. Logging and monitoring is where that test gets concrete. An auditor can see whether you capture security events, whether someone reviews them and whether you act when something looks wrong. This work maps to the monitoring and incident response criteria, often labeled CC7.2 through CC7.4. Without it, a policy is just a document.

Logs do two jobs well. They help you detect an issue and investigate what happened. They also prove later that you handled it. A failed sign-in spike, a new admin role, a production deploy at 2 a.m. and a backup job that stopped all show up in logs before they show up in a customer ticket. The audit sample will follow those events from source to review to action.

Monitoring is wider than security. Certificate expiry, disk pressure, failed payment jobs and queue depth belong in the same operating rhythm. Give one person ownership of the pipeline and one person ownership of the review queue. Split those roles in small teams if you can, so the person who can change production is not the only person watching the logs.

Before you start

List every system that can create a security or operational event. Cover your identity provider, cloud accounts, production hosts, databases, the app, the network, endpoints, code repo, CI/CD, backup tool and any SaaS admin console that can change access. For each one, write down the source, the event types you need, where the logs go, who owns them and how long you keep them.

Choose one central place to search. A cloud log service, a SIEM, or a self-hosted OpenSearch or ELK stack all work. Compare them on query speed, retention cost, access control and how easy it is to export evidence. Keep audit logs in a separate account or project from the systems they describe. Give engineers read access only when they need it, and keep delete rights with a small group.

Set retention before you turn on collection. A Type II report covers a period, so your logs must survive that period plus enough time for the auditor to sample them. Many teams keep 30 to 90 days hot for search and a year or more in cold storage. Check contracts and data handling rules for your own customer data, then write the rule down. Do not log passwords, session tokens, API keys or full payment data. Use field redaction or drop those fields at the source.

How to do it

Start with sources that answer who did what to which system. Identity provider sign-in and MFA changes, cloud control plane changes, production host logins, application admin actions, code repository changes and CI/CD deploys carry the most weight. Add backup, vulnerability and network tools once the core pipeline is stable. A small set of sources that you review beats a huge set that nobody opens.

Split the work into collection, protection, detection and review. Collection without protection gives you logs an attacker can edit. If you protect logs but never alert on them, you have an archive. If you alert but never review, the channel fills up and people stop looking. Build each layer and assign an owner.

Make alerts actionable. Each rule needs a name, a severity, an owner, a runbook and a destination. High severity goes to the on-call rotation and opens a ticket. Low severity goes to a weekly review queue. When a rule fires, the responder records what they checked, what they found and what they changed. That record is the evidence an auditor will ask for.

1. Inventory sources and owners. Build a spreadsheet with system, log source, event types, destination, retention and owner. Include SaaS admin consoles, serverless functions and databases, not only servers. Review it every quarter and after any new system goes live.
2. Turn on native audit logs first. Enable CloudTrail with log file validation, Entra ID sign-in logs, Google Cloud Audit Logs or the equivalent in your stack. Send them to the central store and set clocks with NTP or chrony. Native audit logs are harder to tamper with than app logs you wrote yourself.
3. Centralize and lock down the log store. Use a separate account or project for logs. Turn on object lock, immutable blob storage or a bucket retention policy. Give the application and engineers write-only or read-only roles as needed. Test that an admin in the production account cannot delete the log bucket.
4. Write retention and redaction rules. Document hot and cold retention, who can query logs and what fields are dropped. Set lifecycle rules so data moves to cheaper storage, not to the bin. Redact secrets and customer identifiers at ingest when you can.
5. Build alerts for high-value events. Start with root account use, MFA disabled, a new admin role, repeated failed sign-ins, a security group open to the internet, a production deploy outside the change window, backup failure and the log pipeline stopping. Give each rule an owner and a runbook link. Route high severity to on-call and a ticket.
6. Set a review cadence. Review high alerts daily, low alerts weekly and the log source inventory monthly. Use a ticket template with what fired, what you checked, what you found and the follow-up, and keep the review short and repeatable. A calendar entry with a named owner works better than a chat channel.
7. Test one alert end to end. Create a safe test event, such as a failed sign-in from a test account or a temporary rule match. Confirm the log arrives, the alert fires, the ticket opens and the on-call acknowledges it. Fix routing before the auditor asks.
8. Package evidence monthly. Export alert rule settings, review tickets, incident records and a sample log query. Store them in a dated folder with the control name. Record any rule changes and why they happened. This makes the audit sample much faster.

How to check it worked

Run one test per quarter from end to end. Trigger a safe event, watch it land in the central store, confirm the alert fires and check that the ticket reaches the right person. Open the runbook and see whether someone outside the team can follow it. If the test only proves that a dashboard turns red, it is not enough.

Pick a random privileged action from last month, such as a role change or a new access key. Trace it from the source log to the central store to the review ticket. Check that timestamps match in UTC and that the actor is a named person, not a shared account. Then query the oldest log you claim to keep and confirm it is still there.

Check protection with the same care. Confirm the log bucket is not public, that production admins cannot delete it and that the pipeline health alert works when a source stops sending. Ask an engineer to try to change a log retention rule without approval. The attempt should show up in the audit log and in a ticket.

Keep a control sheet with the source list, retention, alert rules, review tickets and test dates. Walk an auditor through that sheet and one real event. If you cannot explain the path in plain words, simplify the pipeline before the audit starts.

Mistakes to avoid

A common gap is collecting logs without a review. An auditor will ask who looked, when and what happened next. If the answer is a dashboard nobody opens, the control is not operating. Noisy alerts cause the same failure. A channel full of unread alerts is worse than a short list with an owner.

Do not delete logs before the audit period ends, and do not leave them editable by the same admins who manage production. Shared admin accounts ruin attribution. Logging secrets, tokens or full customer records creates a new problem. Set redaction rules and test them.

A vendor's SOC 2 report does not cover your configuration. It tells you something about the vendor, not whether you turned on audit logs and reviewed what landed in your own store. Also watch the gaps: serverless functions, managed databases, SaaS admin consoles and CI/CD systems often get missed. Monitor the pipeline itself, because a silent source looks the same as a quiet week.

If you want a structured second look before the audit, the Cloudverg SOC 2 readiness assessment is a fixed price engagement at $7,500. It covers scoping, a gap assessment, an evidence inventory and a remediation roadmap. It is one option among several, and it works best when you already have logs flowing.

Frequently asked questions