Free compliance framework explorer — browse controls, evidence, and implementation guidance.Subscribe for updates →
BETA
SOC 247
ITSP.10.17198
ISO 42001soon
ISO 27001soon
Browse
Ctrl+K
33 controls
CC1.1
Commitment to integrity and ethical values
Control Environment
6 evidence2 controls
CC1.2
Board independence and oversight of internal control
Control Environment
3 evidence1 control
CC1.3
Organizational structure, reporting lines, and authority
Control Environment
3 evidence1 control
CC1.4
Commitment to attract, develop, and retain competent individuals
Control Environment
6 evidence2 controls
CC1.5
Accountability for internal control responsibilities
Control Environment
3 evidence1 control
CC2.1
Obtains or generates and uses relevant quality information
Communication and Information
3 evidence1 control
CC2.2
Internal communication of information to support internal control
Communication and Information
6 evidence2 controls
CC2.3
External communication regarding matters affecting internal control
Communication and Information
4 evidence1 control
CC3.1
Specifies objectives with sufficient clarity
Risk Assessment
3 evidence1 control
CC3.2
Identifies and analyzes risks to achievement of objectives
Risk Assessment
3 evidence1 control
CC3.3
Considers potential for fraud in assessing risks
Risk Assessment
3 evidence1 control
CC3.4
Identifies and assesses significant changes
Risk Assessment
3 evidence1 control
CC4.1
Selects, develops, and performs ongoing and separate evaluations
Monitoring Activities
6 evidence2 controls
CC4.2
Evaluates and communicates internal control deficiencies
Monitoring Activities
3 evidence1 control
CC5.1
Selects and develops control activities that mitigate risks
Control Activities
3 evidence1 control
CC5.2
Selects and develops general controls over technology
Control Activities
6 evidence2 controls
CC5.3
Deploys control activities through policies and procedures
Control Activities
3 evidence1 control
CC6.1
Logical access security infrastructure
Logical and Physical Access Controls
11 evidence3 controls
CC6.2
Registration and authorization prior to issuing credentials
Logical and Physical Access Controls
6 evidence2 controls
CC6.3
Role-based access management
Logical and Physical Access Controls
6 evidence2 controls
CC6.4
Physical access restrictions
Logical and Physical Access Controls
3 evidence1 control
CC6.5
Disposal and destruction of information assets
Logical and Physical Access Controls
3 evidence1 control
CC6.6
Controls against threats from outside system boundaries
Logical and Physical Access Controls
8 evidence2 controls
CC6.7
Restricts transmission and movement of information
Logical and Physical Access Controls
7 evidence2 controls
CC6.8
Controls to prevent or detect unauthorized software
Logical and Physical Access Controls
6 evidence2 controls
CC7.1
Detection and monitoring for vulnerabilities
System Operations
8 evidence2 controls
CC7.2
Monitoring for anomalies and security events
System Operations
4 evidence1 control
CC7.3Evaluation of security events as security incidentsSOC 2System Operations
Official Requirement
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.
Not every alert is an incident, but you need a documented decision process for making that call. When an alert fires, someone evaluates it, decides whether it's a security incident, and if so, triggers the incident response process. The evaluation itself needs to be recorded, auditors want to see that triage happened and that the criteria for 'incident' are defined, not ad-hoc.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Documented incident classification and triage process
Implementation Steps
Define incident severity tiers in your Incident Response Plan: P1 (confirmed breach or data exfiltration), P2 (active attack, contained), P3 (suspected compromise, investigating), P4 (security event of interest, no immediate threat)
For each alert that fires, require the analyst to document: alert source, initial assessment, severity classification, and rationale for closing as false positive or escalating as incident
Build a Jira or ServiceNow workflow with incident type categories, this forces structured triage rather than Slack threads that disappear
Conduct a monthly review of all P3 and P4 events to identify patterns that individually look benign but collectively suggest a threat
Typical Control Documented incident classification and triage process
Evidence Artifacts
Incident Response Plan excerpt showing severity classification tiers with definitions
Jira incident ticket showing: event description, severity assigned, analyst notes, and closure with rationale
Monthly event review meeting notes or summary report showing P3/P4 events were reviewed collectively
Incident Register for the audit period (even if empty, a signed attestation of zero incidents is acceptable)
📅Per-alert triage documentation; monthly pattern review; annual IR plan review
Cross-framework mappings coming in v1.1
When we add ISO 42001 and ISO 27001, you'll see which controls map to this criterion.
ISO
ISO 42001
AI Management Systems
ISO
ISO 27001
Information Security
Mapping data will appear here automatically when the frameworks are published.
CC7.4
Incident response program
System Operations
4 evidence1 control
CC7.5
Recovery from security incidents
System Operations
4 evidence1 control
CC8.1
Authorized change management process
Change Management
8 evidence2 controls
CC9.1
Risk mitigation for business disruptions
Risk Mitigation
4 evidence1 control
CC9.2
Vendor and business partner risk management
Risk Mitigation
4 evidence1 control
Help us build what matters.
Vote for the next framework, subscribe for updates, and let us know if you'd contribute.
What should we add next?
Vote for the framework you need most.
0
ISO 42001
0
ISO 27001
0
CMMC
0
CPCSC
Stay Updated
Get notified when new frameworks and features are added.
On-premises implementation and evidence
Documented incident classification and triage process
Implementation steps
Document incident severity tiers in the Incident Response Plan with concrete examples (e.g., P1: ransomware active on a production server; P2: unauthorized admin account created; P3: repeated failed SSH logins from external IP)
For each your SIEM/monitoring platform or your IDS/network monitoring platform alert the ISM reviews, log the assessment in the Security Monitoring Log: alert ID, severity, analyst assessment, escalated Y/N, and if escalated, the IR ticket number
Maintain an Incident Register: a running list of all confirmed security incidents during the audit period with date, classification, and resolution summary
Ensure the IR Plan defines the decision criteria for when to notify leadership, legal, or customers, auditors will ask whether you have escalation thresholds
Tools / systems
Wazuh (event source)
Security Onion (event source)
Incident Response Plan (policy)
Evidence artifacts
Incident Response Plan severity tier definitions section
Security Monitoring Log entries showing events were assessed and classified during the audit period
Incident Register for the audit period with confirmed incidents or management attestation of none
Evidence of escalation thresholds: the IR Plan section covering when to notify leadership and customers
Evidence frequency: Per-alert logging; Incident Register maintained continuously; IR Plan reviewed annually
