Controls are the fundamental building blocks of any compliance framework. Understanding what controls are and how they function in DSALTA is essential for effective compliance management.
Defining Compliance Controls
A compliance control is a specific security requirement or safeguard that organizations must implement to protect data, systems, and operations. Controls define what you must do to be compliant, while evidence and tests prove you're actually doing it.
Example Controls:
"Multi-factor authentication (MFA) is required for all user accounts"
"Encryption is enabled for data at rest and in transit"
"Background checks are performed on all employees with access to sensitive data"
"System logs are retained for at least one year"
Each control addresses a specific security concern and contributes to your overall security posture.
Control Components in DSALTA
Every control in DSALTA contains several key elements:
Control ID and Name
Unique identifier and descriptive name. For example:
CC6.1: "The entity implements logical access security software"
A.9.2.1: "User registration and de-registration"
IDs reference the source framework's numbering system, making it easy to cross-reference with framework documentation.
Control Description
Clear explanation of what the control requires. Descriptions specify:
The security objective
What must be implemented
Who is responsible
When/how often it applies
Risk Level
Indicates the control's criticality:
Critical: Fundamental security controls (access management, encryption)
High: Important security measures (monitoring, incident response)
Medium: Supporting controls (documentation, training)
Low: Administrative controls (policy reviews, reporting)
[Screenshot needed: Control detail view showing ID, description, and risk level]
Control Owner
The team member responsible for implementing and maintaining this control. Ownership ensures accountability and clear responsibility.
Mapped Frameworks
Shows which frameworks this control satisfies. A single control often applies to multiple frameworks, reducing duplicate work.
Evidence Requirements
Lists what documentation, artifacts, or proof is needed to demonstrate control implementation:
Policy documents
Configuration screenshots
Access logs
Test results
Training records
Associated Tests
Automated or manual tests that verify control effectiveness. Tests run periodically to ensure controls remain operational.
Control Categories
Controls are typically organized into categories reflecting different security domains:
Access Control: User authentication, authorization, and access management Asset Management: Inventory and protection of organizational assets Cryptography: Encryption and key management Physical Security: Facility protection and environmental controls Operations Security: System maintenance and monitoring Communications Security: Network and data transmission protection System Development: Secure development lifecycle practices Compliance: Legal, regulatory, and contractual requirements Business Continuity: Disaster recovery and continuity planning Incident Management: Security event detection and response
Categories help organize controls logically and assign ownership by functional area.
Control Types
Controls serve different purposes in your security program:
Preventive Controls
Stop security issues before they occur
MFA preventing unauthorized access
Encryption preventing data exposure
Firewalls blocking malicious traffic
Detective Controls
Identify security issues when they happen
Log monitoring detecting suspicious activity
Intrusion detection systems alerting on threats
Access reviews identifying inappropriate permissions
Corrective Controls
Respond to and remediate security issues
Incident response procedures
Patch management processes
Backup and recovery systems
Most comprehensive security programs include all three types, creating defense in depth.
Control Status in DSALTA
DSALTA tracks each control's implementation status:
Not Started (Gray): No implementation activity yet In Progress (Yellow): Partially implemented or missing evidence Completed (Green): Fully implemented with passing tests and complete evidence Needs Attention (Red): Previously passing but now has failing tests or missing evidence
Status updates automatically based on evidence collection and test results.
[Screenshot needed: Control list showing different status indicators]
Control Inheritance and Mapping
Many controls apply across multiple frameworks with slightly different wording but the same fundamental requirement. DSALTA maps these overlapping controls so you implement once and satisfy multiple frameworks.
Example:
SOC 2 CC6.1: "Logical access security software"
ISO 27001 A.9.4.1: "Information access restriction"
NIST 800-53 AC-3: "Access Enforcement"
All three require the same basic implementation: restricting system access to authorized users. DSALTA maps these as a single control, with evidence and tests satisfying all three frameworks simultaneously.
Control Frequency
Different controls require different maintenance frequencies:
Continuous: Automated controls monitored constantly (encryption, MFA enforcement) Daily: System checks and monitoring activities Weekly/Monthly: Regular reviews and updates Quarterly: Access reviews, security assessments Annually: Policy reviews, comprehensive audits
DSALTA tracks these frequencies and alerts you when periodic activities are due.
Why Controls Matter
Controls aren't just checkbox exercises—they represent real security improvements:
Risk Reduction: Each control mitigates specific threats and vulnerabilities Customer Trust: Demonstrated controls prove security commitments Audit Success: Complete control implementation enables certification Security Foundation: Controls create comprehensive security programs Continuous Improvement: Regular control monitoring improves security over time
Control vs. Policy vs. Test
Understanding the distinction helps clarify compliance work:
Control: What you must do (the requirement) Policy: How you've decided to do it (your documented approach) Test: Proof that you're actually doing it (verification)
Example:
Control: "Encryption must protect data at rest"
Policy: "We use AES-256 encryption for all databases and file storage"
Test: Automated check verifying AES-256 is enabled on all databases
All three work together to demonstrate compliance.
Control Ownership Best Practices
Assign control ownership based on functional expertise:
Engineering/IT: Technical controls (encryption, access, monitoring) HR: Personnel controls (background checks, training, offboarding) Legal: Compliance and contractual controls Finance: Financial and SOX-related controls Security Team: Overall coordination and high-risk controls
Clear ownership ensures controls don't fall through organizational gaps.
Controls in the Compliance Journey
Phase 1 - Discovery: Review which controls apply to your frameworks Phase 2 - Planning: Assign ownership and plan implementation Phase 3 - Implementation: Put controls in place and document them Phase 4 - Validation: Run tests and gather evidence Phase 5 - Maintenance: Monitor continuously and update as needed
DSALTA guides you through each phase for every control.
Next Steps
Now that you understand controls:
Review controls for your active frameworks
Identify controls already met through existing security measures
Prioritize controls based on risk level and framework requirements
Begin assigning ownership to team members
Focus on high-risk controls first