Skip to content
AuditFront
OPS-7 Tech Due Diligence

Tech Due Diligence OPS-7: Security Operations and Audit Logging

What This Control Requires

The assessor evaluates security operations capabilities, including audit logging, log retention, security event monitoring, intrusion detection, and the overall ability to detect, investigate, and respond to security threats in the operational environment.

In Plain Language

If someone breached your system tonight, would you know about it? Could you figure out what they accessed, how they got in, and how long they had been there? Security operations covers the ongoing work of monitoring, detecting, and responding to threats in your production environment.

Assessors check audit logging coverage (which security-relevant events are captured), log centralisation and retention (are logs collected somewhere durable and searchable), security event monitoring (are suspicious patterns flagged), intrusion detection at both network and application level, incident response readiness (can the team actually investigate a breach), and access logging for production systems.

Audit logging is especially critical for compliance (SOC 2, ISO 27001, GDPR) and post-incident forensics. Without comprehensive logs, you cannot determine a breach's scope, identify what data was compromised, or demonstrate to regulators what happened. Assessors also check that logs are protected from tampering - if an attacker can delete the evidence, the logs are not doing their job.

How to Implement

Log all security-relevant events. At minimum, capture authentication events (login attempts, failures, MFA), authorisation events (access denials, privilege changes), data access events (reads and writes to sensitive data), administrative actions (user management, config changes), API access (all calls with authentication context), and infrastructure access (SSH sessions, console logins, database connections).

Use a consistent structure for audit log entries: timestamp in UTC, event type, actor (user ID, IP address, user agent), action performed, resource affected, outcome (success or failure), and a request/correlation ID for traceability.

Centralise and protect your logs. Ship them to a tamper-resistant log store where application developers cannot modify or delete entries. Keep log storage separate from application infrastructure. Encrypt logs at rest and in transit. Set retention periods that meet compliance requirements - typically one to seven years depending on regulation.

Set up security-specific monitoring and alerting. Configure alerts for multiple failed login attempts (brute force detection), access from unusual locations or devices, privilege escalation, access to sensitive data outside normal patterns, administrative changes at odd hours, and high-volume data exports or API access that could indicate exfiltration.

Deploy intrusion detection appropriate for your setup: a web application firewall (WAF) for HTTP-level threats, network-level IDS for infrastructure threats, endpoint detection and response (EDR) for server monitoring, and cloud-native security services (GuardDuty, Security Center) for cloud API monitoring.

Define security investigation procedures. Cover how alerts are triaged, who has access to investigate, what forensic tools are available, how findings are escalated, and how evidence is preserved for potential legal proceedings.

Actively monitor your logs - do not just collect them. Consider a Security Operations Centre (SOC), whether internal or outsourced, for continuous monitoring. Someone needs to be watching.

Evidence Your Auditor Will Request

  • Audit logging configuration covering all security-relevant events
  • Centralised log storage with tamper-protection and retention configuration
  • Security monitoring alerts and their configuration
  • Intrusion detection capabilities (WAF, IDS/IPS, EDR, cloud security services)
  • Security investigation procedures and evidence of past investigations

Common Mistakes

  • Insufficient audit logging; critical security events not captured
  • Logs stored locally on application servers; lost if servers are compromised or recycled
  • No security-specific monitoring; reliance on general application alerts only
  • Audit logs include sensitive data that should be excluded
  • No intrusion detection; malicious activity could persist undetected for extended periods

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.15 Related
ISO 27001 A.8.16 Related
SOC 2 CC7.2 Related

Frequently Asked Questions

How long should audit logs be retained?
It depends on your regulatory landscape. SOC 2 typically expects one year. GDPR and financial regulations may require three to seven years for certain records. A sensible default is one year for detailed logs and three years for summary or audit-level logs. Balance retention against storage costs and privacy considerations.
Do we need a SOC (Security Operations Centre)?
A full internal SOC is beyond most growth-stage companies. But some form of security monitoring is non-negotiable. Options include managed SOC services (MDR providers), cloud-native security monitoring (AWS GuardDuty, Azure Sentinel), automated alerting with manual investigation, or a fractional security analyst. The key thing assessors want to see is evidence that someone is actually watching for security events.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment