The technology infrastructure supporting your security program is itself controlled. This means your monitoring tools are reliable, your logging infrastructure is complete, your GRC platform has not been tampered with, and the technology you rely on to enforce controls has its own security controls. It is not enough to say you have a SIEM if anyone can delete SIEM logs without detection.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Log integrity and SIEM infrastructure controls
Implementation Steps
Ensure that CloudTrail (AWS) or Azure Monitor logs are stored in a separate account or storage container that production workload identities cannot modify or delete, log integrity requires separation of the logging plane from the workload plane
Enable CloudTrail log file validation or Azure Monitor log immutability to detect if log files have been tampered with
Restrict who can disable or delete logging, in AWS, use a Service Control Policy (SCP) at the organization level to prevent any role from disabling CloudTrail
Monitor the monitoring infrastructure itself: if your monitoring platform or your SIEM stops receiving logs, that is a detection event requiring an alert
Tools / Systems
AWS CloudTrail with log validation (separate account)AWS Organizations SCPs (prevent logging disable)Azure Monitor with immutable log storageDatadog (SIEM health monitoring)GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Typical Control GRC platform access controls and configuration management
Implementation Steps
Restrict GRC platform (your GRC platform, Drata, or Vanta) admin access to named individuals; not every engineer should be able to modify control status or delete evidence
Enable MFA on the GRC platform and apply SSO where supported, the tool that holds your compliance evidence must be at least as well-protected as your production environment
Review GRC platform user access quarterly; remove accounts for staff who have left or changed roles
Enable audit logging in the GRC platform so changes to control status, evidence uploads, and policy acknowledgements are traceable
Tools / Systems
Okta (SSO for GRC platform)GRC platform audit logGRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Typical Control Log integrity and SIEM infrastructure controls
Evidence Artifacts
AWS CloudTrail configuration showing log file validation enabled and logs stored in a separate account
SCP or IAM policy confirming that CloudTrail cannot be disabled by production roles
Alert configuration showing that SIEM health monitoring is active and logging gaps trigger notifications
📅Configuration reviewed at each audit window; alerts verified continuously
Typical Control GRC platform access controls and configuration management
Evidence Artifacts
GRC platform user list showing admin access is restricted to named individuals
Screenshot confirming MFA and SSO are enabled on the GRC platform
Quarterly access review record for GRC platform users
📅Quarterly access review; configuration reviewed at audit window
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.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
Log integrity and SIEM infrastructure controls
Implementation steps
Configure your SIEM/monitoring platform to forward all logs to a remote log server or your IDS/network monitoring platform node that production server administrators cannot directly access, this prevents log tampering by insiders with server access
Enable your SIEM/monitoring platform file integrity monitoring (FIM) on critical log directories to detect if log files are modified or deleted
Restrict access to the your SIEM/monitoring platform manager and your IDS/network monitoring platform consoles to the security team only, separate credentials from production system administration
Alert when logging gaps occur: if a vulnerability/configuration management agents goes silent or your IDS/network monitoring platform stops receiving traffic from a segment, that is a monitoring failure requiring investigation
Tools / systems
Wazuh (SIEM with remote log forwarding)
Security Onion (NSM and log aggregation)
Wazuh (log collection/HIDS) FIM (file integrity monitoring)
Active Directory (restricted access to security tools)
RADIUS (separate admin access for security infrastructure)
GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Evidence artifacts
Wazuh configuration showing remote log forwarding to a protected log server
Wazuh FIM configuration showing critical log directories are monitored for changes
Access control list for Wazuh and Security Onion consoles showing restricted access
Evidence frequency: Configuration reviewed at each audit window; FIM alerts active continuously
GRC platform access controls and configuration management
Implementation steps
Limit your GRC platform or your GRC tool admin access to the security team; read-only access is appropriate for most staff
Apply the same access control standards to GRC tooling as to production systems: MFA required, access reviewed quarterly, offboarding includes GRC access revocation
Maintain the configuration of your GRC integrations (cloud connectors, SIEM integrations) as documented and reviewed, connector failures mean monitoring gaps
Tools / systems
Okta (SSO and MFA for GRC platform)
Quarterly access review process
GRC platform (e.g., Vanta, Drata, your GRC platform, Scrut)
Evidence artifacts
GRC platform admin user list with role assignments
MFA configuration confirmation for GRC platform access
Offboarding evidence confirming GRC access was revoked for departed staff
