SOC 2 CC7.3: System Operations - Evaluation of Security Events
What This Control Requires
The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
In Plain Language
Your SIEM fires off hundreds of alerts a week. Most are noise. A few might be a real breach in progress. CC7.3 is about having a structured process to tell the difference - quickly and consistently.
Not every security event is an incident. You need trained people who can analyse events, a classification framework for determining severity, clear escalation criteria, and a defined process for moving from detection to response. Speed matters here - delays in classifying events let incidents get worse.
Auditors want to see a defined evaluation process, evidence that events are assessed promptly, consistent application of classification criteria, and a documented trail from initial detection through to either closure (non-incident) or escalation (confirmed incident).
How to Implement
Build a security event classification framework. Define clear criteria for separating security events (any observable occurrence relevant to security) from security incidents (events that actually or potentially compromise confidentiality, integrity, or availability).
Set up severity levels for incidents. A practical model: Critical (significant breach or compromise with immediate business impact), High (confirmed incident with potential for significant impact), Medium (incident with limited scope), Low (minor event without significant operational impact). Give specific criteria and examples for each level.
Define your triage process. When a security event comes in, who does the initial assessment? What information gets gathered? What tools are used? What are the decision criteria for escalation versus closure? Document triage decisions with rationale.
Map out escalation procedures by severity. Critical events should trigger immediate incident response team activation and executive notification. High events go to the security team lead. Medium and low events flow through normal operational channels. Add time-based escalation for events that sit untriaged beyond defined windows.
Train your security operations team on the evaluation process. Cover common attack patterns, indicators of compromise, forensic analysis basics, and your specific classification criteria. Run tabletop exercises that practise evaluation and escalation decisions.
Keep records of every security event evaluated: the initial alert, investigation performed, classification decision, rationale, and resulting action. Use these for trend analysis, process improvement, and audit evidence. Review the evaluation process periodically for consistency.
Evidence Your Auditor Will Request
- Security event classification framework with severity levels and criteria
- Event triage procedures documenting the assessment and escalation process
- Security event evaluation records showing analysis, classification, and disposition
- Escalation procedures and evidence of timely escalation for confirmed incidents
- Training records for security operations personnel on event evaluation procedures
Common Mistakes
- No formal classification framework exists, leading to inconsistent event assessment across analysts
- Security events are not evaluated in a timely manner, allowing incidents to escalate unnecessarily
- Evaluation records are incomplete, making it difficult to demonstrate the rationale for classification decisions
- Low-severity events are ignored entirely rather than being documented and tracked for pattern analysis
- Escalation procedures are not defined or are not followed, resulting in delayed response to significant incidents
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| ISO 27001 | ISO 27001 A.5.25 (equivalent mapping) | Equivalent |
| ISO 27001 | ISO 27001 A.6.8 (related mapping) | Related |
| nist-csf | nist-csf DE.AE-03 (equivalent mapping) | Equivalent |
Frequently Asked Questions
What is the difference between a security event and a security incident?
How quickly should security events be evaluated?
Who should be authorized to classify events as incidents?
Related Articles
The True Cost of Compliance: DIY vs Consultant vs Platform (2026)
A realistic comparison of three compliance approaches - DIY spreadsheets, hiring a consultant, or using a platform - with costs, timelines, and tradeoffs.
Read article →ISO 27001 vs SOC 2: Which Do You Need?
A clear comparison of ISO 27001 and SOC 2 - key differences, when to choose which, where they overlap, and whether you should pursue both.
Read article →SOC 2 for Startups: When You Need It and How to Get Started
A practical guide for startup founders and CTOs on SOC 2 compliance - when it's actually required, Type 1 vs Type 2, realistic costs, and a readiness checklist.
Read article →Track SOC 2 compliance in one place
AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.
Start Free Assessment