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.1Selects and develops control activities that mitigate risksSOC 2Control Activities
Official Requirement
COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
The controls you have chosen are actually matched to your risks. If your top risk is unauthorized access to production databases, your controls address that specific scenario, not just generic IT hygiene. This criterion asks whether there is a traceable line from your risk register to your control set. Controls that exist but do not address any documented risk are evidence of a checkbox program, not a real one.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Risk-to-control mapping in the risk register
Implementation Steps
For each risk in the risk register, document the specific controls that mitigate it, not just a policy reference, but the actual operational control (e.g., 'MFA enforcement on all production access via Okta conditional access policy')
When selecting new controls, trace the selection back to a documented risk: what risk does this control reduce, by how much, and what is the residual risk after the control is applied?
Review the risk-to-control mapping annually as part of the risk assessment cycle, confirm that controls added during the year were in response to documented risks, not ad-hoc additions
Use your GRC platform to link controls to risks; your GRC platform and Drata both support this linkage in their risk modules
Annual risk assessment documentation confirming control selection was reviewed against the risk landscape
📅Annual review; updated when new risks are identified or controls change
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.
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.3
Evaluation of security events as security incidents
System Operations
4 evidence1 control
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
Risk-to-control mapping in the risk register
Implementation steps
In your risk register, add a column for 'Mitigating Controls' and populate it with specific control references (e.g., control IDs from your GRC platform or your internal control library)
When a new risk is added, immediately identify whether existing controls already address it (and the control is sufficient) or whether a new control needs to be designed
Document the control selection rationale: why this control was chosen over alternatives, and how it specifically addresses the threat scenario
Tools / systems
Control design documentation
Risk Assessment Policy
GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Evidence artifacts
Risk register with mitigating control column populated for each identified risk
Control selection rationale document or notes from the risk assessment process
Annual risk assessment sign-off confirming control adequacy was reviewed
Evidence frequency: Annual; updated per new risk identification
