1. Purpose
The Requirement-to-Control Mapping Matrix is a structured record used to connect organizational requirements to the security controls, policies, procedures, processes, owners, and evidence used to address those requirements.
It helps the organization demonstrate:
What requirement applies, why it applies, which control addresses it, who owns the control, what evidence exists, and whether the requirement is effectively addressed.
The matrix can connect requirements from:
- Legal requirements
- Regulatory requirements
- Contractual requirements
- Customer requirements
- Business requirements
- Information-security risks
- Internal policies
- Industry requirements
- Certification requirements
- Interested-party requirements
2. Core Principle
A requirement should not simply be listed.
The organization should be able to trace:
Requirement → Obligation → Risk → Control → Implementation → Evidence → Owner → Review
This creates a defensible audit trail between external requirements and the organization’s ISMS.
3. When to Use
Use the matrix when:
- Establishing an ISMS
- Performing a gap assessment
- Developing the Statement of Applicability
- Mapping legal requirements
- Reviewing customer contracts
- Assessing regulatory requirements
- Performing risk treatment
- Preparing for an ISO 27001 audit
- Reviewing control effectiveness
- Implementing new security requirements
- Assessing new customers
- Introducing new products or services
- Reviewing significant business or technology changes
4. Requirement Sources
Identify the source of each requirement.
| Source | Example |
|---|---|
| Legal | Applicable privacy law |
| Regulatory | Financial-sector requirement |
| Contractual | Customer security clause |
| Customer | Customer security questionnaire |
| Business | Availability requirement |
| Risk | Risk treatment requirement |
| Policy | Internal security policy |
| Industry | PCI DSS |
| Certification | ISO 27001 certification commitment |
| Supplier | Supplier security requirement |
| Management | Management-approved security objective |
5. Master Requirement-to-Control Matrix
The following is the primary matrix.
| Requirement ID | Requirement | Source | Obligation | Risk | Control | Policy/Procedure | Owner | Evidence | Status |
|---|---|---|---|---|---|---|---|---|---|
| REQ-001 | Protect customer information | Contract | Restrict unauthorized access | High | Access Control | Access Control Policy | Security | Access Review | Compliant |
| REQ-002 | Notify qualifying incidents | Contract | Notify customer within contractual period | High | Incident Management | Incident Response Procedure | Security | Incident Record | Active |
| REQ-003 | Protect personal data | Legal | Apply appropriate security measures | High | Information Protection | Privacy Policy | Privacy | Privacy Assessment | Active |
| REQ-004 | Recover critical service | Business | Restore service within defined RTO | High | Business Continuity | DR Plan | IT | DR Test Report | Active |
6. Requirement Identification
For each requirement, record:
Requirement ID:
Requirement Name:
Requirement Description:
Source:
Source Reference:
Jurisdiction:
Contract/Clause:
Business Area:
Applicable Service:
Applicable Information:
Applicable System:
Applicability
☐ Applicable
☐ Partially Applicable
☐ Not Applicable
☐ Under Review
Applicability Rationale
7. Requirement Description
Describe the requirement in practical terms.
Avoid recording only:
“Data protection law”
Instead record:
“Customer personal information must be protected against unauthorized access, disclosure, alteration, or loss in accordance with applicable privacy and security requirements.”
This makes the requirement easier to map to operational controls.
8. Requirement Classification
Classify each requirement.
Legal / Regulatory
☐ Law
☐ Regulation
☐ Regulatory guidance
☐ Government requirement
Contractual
☐ Customer contract
☐ Supplier contract
☐ DPA
☐ NDA
☐ SLA
☐ Security addendum
Business
☐ Customer requirement
☐ Availability requirement
☐ Confidentiality requirement
☐ Business continuity requirement
☐ Operational requirement
Security / Risk
☐ Risk treatment
☐ Threat requirement
☐ Vulnerability requirement
☐ Security objective
Industry / Certification
☐ ISO 27001
☐ SOC 2
☐ PCI DSS
☐ Other industry requirement
9. Requirement-to-Obligation Mapping
Identify what the organization actually needs to do.
| Requirement | Obligation |
|---|---|
| Protect customer information | Restrict access |
| Protect personal data | Apply appropriate security controls |
| Contract requires MFA | Enforce MFA |
| Contract requires annual VAPT | Conduct security testing |
| RTO requirement | Maintain recovery capability |
| Data deletion requirement | Securely delete data after applicable retention period |
The obligation should be sufficiently clear that an operational team can understand what action is expected.
10. Requirement-to-Risk Mapping
A requirement may create or influence information-security risk.
| Requirement | Risk | Risk ID | Risk Level | Treatment |
|---|---|---|---|---|
| Protect customer data | Unauthorized access | R-001 | High | Access controls |
| Annual VAPT | Vulnerability remains exploitable | R-002 | High | Security testing |
| Incident notification | Delayed customer notification | R-003 | Medium | Incident procedure |
| RTO commitment | Extended service outage | R-004 | High | DR capability |
This connects contractual/legal obligations with the ISMS risk-management process.
11. Requirement-to-Control Mapping
For each requirement, identify the control or controls that address it.
| Requirement | Control | Control Purpose | Implementation |
|---|---|---|---|
| Protect customer data | Access control | Prevent unauthorized access | IAM + MFA + access review |
| Protect data in transit | Encryption | Protect information during transfer | TLS |
| Detect security incidents | Logging/monitoring | Identify suspicious activity | CloudTrail + monitoring |
| Recover critical service | Backup/DR | Restore service | Backup + DR |
One requirement may map to multiple controls.
One control may also address multiple requirements.
12. ISO/IEC 27001 Annex A Mapping
Where applicable, map the requirement to relevant Annex A controls.
| Requirement | ISO 27001 Annex A Control | Reason |
|---|---|---|
| Protect customer information | A.5.12 | Information classification |
| Restrict access | A.5.15 | Access control |
| Secure authentication | A.8.5 | Secure authentication |
| Protect information during transfer | A.5.14 | Information transfer |
| Manage vulnerabilities | A.8.8 | Management of technical vulnerabilities |
| Incident response | A.5.24–A.5.28 | Information security incident management |
| Business continuity | A.5.29–A.5.30 | Security during disruption / ICT readiness |
The organization should determine the exact applicable controls through its risk assessment and Statement of Applicability.
Annex A should not be treated as a standalone checklist where every control automatically becomes applicable.
13. Non-Annex-A Controls
Not every requirement needs to map only to Annex A.
The organization may have controls that are:
- Custom controls
- Business controls
- Application controls
- Contract-specific controls
- Privacy controls
- Financial controls
- Operational controls
- Customer-specific controls
Example:
Customer requires a specific monthly security report.
The organization may implement a reporting process even though there may not be a single Annex A control specifically named “monthly customer security report.”
Record such controls where they are necessary to meet the requirement.
14. Control Implementation
Document how the control is actually implemented.
Example
Requirement: MFA required for privileged access.
Control: Secure authentication.
Implementation:
- MFA enabled
- Privileged accounts identified
- Named accounts used
- Administrative access restricted
- Access logged
- Periodic review performed
Evidence:
- IAM configuration
- Access review
- Authentication logs
- Approval records
15. Policy and Procedure Mapping
Map each control to supporting documentation.
| Control | Policy | Procedure | Record |
|---|---|---|---|
| Access Control | Access Control Policy | Access Review Procedure | Access Review |
| Incident Management | Incident Management Policy | Incident Response Procedure | Incident Register |
| Backup | Backup Policy | Backup & Restore Procedure | Backup Register |
| Supplier Security | Supplier Security Policy | Supplier Review Procedure | Supplier Review |
| DR | BCP Policy | DR Procedure | DR Test Report |
This helps demonstrate that the control exists at both the governance and operational levels.
16. Evidence Mapping
A control should have appropriate evidence.
| Requirement | Control | Evidence |
|---|---|---|
| MFA | Secure authentication | IAM configuration |
| Access review | Access control | Quarterly access review |
| VAPT | Security testing | VAPT report |
| Backup | Backup controls | Backup logs |
| DR | ICT readiness | DR test report |
| Incident response | Incident management | Incident records |
| Supplier security | Supplier management | Supplier assessment |
Evidence should demonstrate that the control is operating, not merely that a policy exists.
17. Evidence Quality
Consider whether evidence is:
Current
Is the evidence recent enough for the control?
Relevant
Does it actually demonstrate the requirement?
Complete
Does it cover the required scope?
Authentic
Can its source be established?
Traceable
Can the auditor trace it back to the requirement/control?
Repeatable
Can the organization demonstrate that the control operates consistently?
18. Control Owner
Each mapped control should have a defined owner.
Possible owners include:
- CISO
- Security Lead
- IT Manager
- Cloud Engineering
- DevOps
- Engineering
- HR
- Privacy Officer
- Legal
- Compliance
- Procurement
- Business Owner
- Supplier Owner
The owner should have sufficient authority to maintain the control.
19. Requirement Owner
The requirement itself may have a separate owner.
For example:
| Requirement | Requirement Owner | Control Owner |
|---|---|---|
| Customer contract | Account/Legal | Security |
| Privacy requirement | Privacy | Security/IT |
| RTO commitment | Business Owner | IT |
| Supplier requirement | Procurement | Supplier Owner |
This distinction is useful because owning the requirement and operating the control are not always the same responsibility.
20. Control Status
Use consistent status values.
| Status | Meaning |
|---|---|
| Not Started | Control not implemented |
| Planned | Implementation planned |
| In Progress | Implementation underway |
| Implemented | Control implemented |
| Operating | Control operating with evidence |
| Partially Effective | Control exists but has gaps |
| Ineffective | Control does not adequately address requirement |
| Not Applicable | Control not required |
| Under Review | Applicability/effectiveness being assessed |
21. Requirement Compliance Status
Separately track the requirement itself.
| Status | Meaning |
|---|---|
| Not Assessed | Requirement not evaluated |
| Applicable | Requirement applies |
| Compliant | Requirement adequately addressed |
| Partially Compliant | Some obligations addressed |
| Gap Identified | Requirement not adequately addressed |
| Remediation | Corrective action underway |
| Risk Accepted | Approved risk acceptance |
| Not Applicable | Requirement does not apply |
Do not confuse control implementation status with requirement compliance status.
22. Control Effectiveness
Implementation alone does not prove effectiveness.
Assess:
Design
Does the control adequately address the requirement?
Implementation
Has the control actually been implemented?
Operation
Is the control operating consistently?
Evidence
Is objective evidence available?
Effectiveness
Has the control achieved the intended result?
Example:
MFA policy exists → MFA configured → MFA logs demonstrate use → access review confirms coverage → control is operating.
23. Gap Assessment
Where a requirement is not fully addressed:
| Gap ID | Requirement | Control | Gap | Risk | Action | Owner | Due Date |
|---|---|---|---|---|---|---|---|
| GAP-001 | Customer requires annual VAPT | Security Testing | Test overdue | High | Conduct VAPT | Security | 2027-01-15 |
Link significant gaps to:
- Risk Register
- Corrective Action Tracker
- Risk Acceptance
- ISMS Improvement Log
24. Multiple Controls for One Requirement
A requirement may require several controls.
Example
Requirement: Protect customer information.
Possible controls:
- Information classification
- Access control
- MFA
- Encryption
- Logging
- DLP where appropriate
- Backup
- Supplier security
- Incident response
- Data retention
Therefore, do not force every requirement into a one-to-one mapping.
25. One Control for Multiple Requirements
A single control may satisfy several requirements.
Example
MFA
may support:
- Customer contractual requirement
- Internal security policy
- Risk treatment
- Privileged access requirement
- Regulatory requirement
- ISO 27001 control objective
This is why a matrix is more useful than separate disconnected spreadsheets.
26. Requirement Coverage Assessment
Assess whether all important requirements have appropriate controls.
| Requirement | Controls | Coverage | Gap |
|---|---|---|---|
| Customer data protection | 5 | Strong | None |
| Incident notification | 2 | Partial | Notification workflow |
| DR requirement | 3 | Strong | None |
| Supplier security | 1 | Partial | Monitoring required |
Recommended coverage values:
- Full
- Partial
- Weak
- None
- Not Applicable
27. Control Coverage Assessment
The matrix can also be viewed from the opposite direction.
| Control | Requirements Supported |
|---|---|
| MFA | Customer A, Customer B, Risk R-001 |
| Incident Response | Contract A, DPA, Risk R-005 |
| Backup | BCP, Customer A, Risk R-008 |
| VAPT | Customer B, Risk R-010 |
This helps identify controls that support multiple business requirements.
28. Requirement-to-Policy Mapping
A practical mapping may look like:
Requirement
→ Access Control
→ Access Control Policy
→ Access Review Procedure
→ IAM Configuration
→ Access Review Evidence
This provides traceability from requirement to operational evidence.
29. Requirement-to-SoA Mapping
Where ISO 27001 is being implemented:
Requirement
↓
Risk / Obligation
↓
Control Requirement
↓
Annex A Comparison
↓
Statement of Applicability
↓
Control Implementation
↓
Evidence
The SoA should document the organization’s actual control applicability decisions.
The matrix can therefore support the SoA but should not be treated as a replacement for it.
30. AWS SaaS Startup Example
Consider a SaaS startup operating on AWS.
Requirement
A customer contract requires:
Customer data must be protected against unauthorized access.
Mapping
Requirement
Customer contract
↓
Obligation
Restrict unauthorized access
↓
Risk
Unauthorized access to customer database
↓
Controls
- IAM
- MFA
- Least privilege
- Network controls
- Database access restrictions
- Logging
- Access reviews
↓
AWS Implementation
- IAM roles
- MFA
- Security groups
- RDS access restrictions
- CloudTrail
- CloudWatch
- Secrets Manager
- Periodic access review
↓
Evidence
- IAM configuration
- Access review
- CloudTrail logs
- Security group configuration
- RDS configuration
- Access approval
↓
Review
Periodic control review
This is the type of traceability the matrix should provide.
31. Sample AWS Requirement Mapping
| Requirement | Risk | Control | AWS Implementation | Evidence |
|---|---|---|---|---|
| Customer data protection | Unauthorized access | Access Control | IAM/MFA | Access review |
| Encryption | Data exposure | Encryption | KMS/TLS | Configuration evidence |
| Logging | Undetected activity | Logging | CloudTrail | CloudTrail records |
| Vulnerability management | Exploitation | Vulnerability Management | Scanning/Patching | Scan reports |
| Availability | Service outage | Resilience | Multi-AZ/backup | DR test |
| Incident response | Delayed response | Incident Management | Monitoring + IR process | Incident record |
32. Customer Requirement Example
Suppose a customer requires:
“The service provider shall conduct an independent penetration test at least annually.”
The matrix should record:
| Field | Value |
|---|---|
| Requirement | Annual independent penetration test |
| Source | Customer contract |
| Clause | Security Schedule 7.2 |
| Risk | Undetected exploitable vulnerabilities |
| Control | Security Testing |
| Procedure | VAPT Procedure |
| Owner | Security Lead |
| Evidence | VAPT Report |
| Frequency | Annual |
| Status | Operating |
| Next Due | Record date |
33. Legal Requirement Example
Suppose an applicable privacy requirement requires appropriate security measures.
Mapping:
Legal Requirement
→ Protect personal information
→ Risk of unauthorized disclosure
→ Access control + encryption + logging + incident management
→ Privacy/Security policies
→ Technical implementation
→ Evidence
→ Compliance review
This demonstrates how legal obligations become operational security requirements.
34. Requirement Change Management
When a requirement changes:
- Identify change
- Verify source
- Assess applicability
- Identify changed obligation
- Reassess risk
- Review controls
- Review policies
- Review evidence
- Identify gaps
- Assign corrective action
- Update matrix
- Review SoA where relevant
- Communicate changes
- Verify implementation
35. Periodic Review
Review the matrix based on risk and organizational change.
Review triggers include:
- New regulation
- Regulatory amendment
- New customer
- New contract
- Contract renewal
- New product
- New country
- New data type
- New supplier
- Major technology change
- Security incident
- Audit finding
- Risk reassessment
- New ISO certification scope
- Major business change
36. Matrix Review Checklist
☐ Requirements still applicable
☐ Requirement sources still valid
☐ Contract clauses reviewed
☐ Legal/regulatory changes considered
☐ Risks reviewed
☐ Controls still appropriate
☐ Control owners confirmed
☐ Evidence current
☐ Control effectiveness reviewed
☐ Gaps updated
☐ Corrective actions updated
☐ SoA implications assessed
☐ New requirements added
☐ Obsolete requirements removed or marked
☐ Review completed
37. Minimum Startup Matrix
A startup can initially maintain the following fields:
| Field |
|---|
| Requirement ID |
| Requirement |
| Source |
| Applicability |
| Obligation |
| Risk |
| Control |
| ISO 27001 Control |
| Policy/Procedure |
| Owner |
| Evidence |
| Status |
| Gap |
| Action |
| Due Date |
| Review Date |
This is sufficient to create useful traceability without creating excessive administrative overhead.
38. Common Mistakes
Avoid:
- Mapping every requirement to every ISO control.
- Treating Annex A as a mandatory checklist.
- Mapping controls without understanding the requirement.
- Mapping a policy and assuming the control is effective.
- Failing to identify evidence.
- Having no control owner.
- Ignoring contractual requirements.
- Ignoring business requirements.
- Ignoring controls outside Annex A.
- Using outdated control mappings.
- Marking controls compliant without evidence.
- Creating a matrix that nobody maintains.
- Creating separate disconnected spreadsheets for every framework.
- Failing to reassess mappings after business or regulatory changes.
39. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Legal & Regulatory Requirements Register | Provides legal/regulatory requirements |
| Contractual Security Requirements Register | Provides contractual obligations |
| Interested Parties Register | Provides stakeholder requirements |
| Risk Register | Provides risk-driven control requirements |
| Statement of Applicability | Records ISO 27001 control applicability |
| Control Library | Defines organizational controls |
| Policies | Establish governance requirements |
| Procedures | Define operational activities |
| Evidence Register | Tracks control evidence |
| Internal Audit | Tests control implementation/effectiveness |
| Corrective Action Tracker | Tracks control gaps |
| ISMS Improvement Log | Tracks improvements |
| Management Review | Reviews significant control and requirement issues |
40. Audit Evidence
The matrix itself is useful audit evidence, but stronger evidence comes from the connected records.
An auditor should be able to select a requirement and trace:
Requirement
→ Source
→ Applicability
→ Obligation
→ Risk
→ Control
→ Owner
→ Implementation
→ Evidence
→ Effectiveness
→ Review
→ Corrective Action if Required
This provides a clear chain of accountability.
41. ISO/IEC 27001 Alignment
The Requirement-to-Control Mapping Matrix supports the risk-based ISMS by connecting:
- Interested-party requirements
- Legal and regulatory obligations
- Contractual requirements
- Information-security risks
- Risk treatment
- Security controls
- Statement of Applicability
- Operational implementation
- Documented information
- Monitoring
- Internal audit
- Corrective action
- Continual improvement
The matrix itself is an organizational tool; ISO/IEC 27001 does not prescribe a universal spreadsheet format.
The organization should determine its control applicability through its information-security risk assessment, applicable requirements, and Statement of Applicability.
42. Final Audit Trail
For important requirements, the organization should be able to demonstrate:
Requirement Identified
→ Source Verified
→ Applicability Assessed
→ Obligation Defined
→ Risk Assessed
→ Control Identified
→ ISO/IEC 27001 Mapping Considered
→ Policy/Procedure Mapped
→ Owner Assigned
→ Control Implemented
→ Evidence Collected
→ Effectiveness Assessed
→ Gap Identified Where Applicable
→ Corrective Action Assigned
→ Requirement Reviewed
→ Control Updated Where Necessary
→ Management/ISMS Records Updated
43. Final Principle
A Requirement-to-Control Mapping Matrix is the bridge between what the organization is required to do and how the organization actually protects information.
The goal is not to create a large compliance spreadsheet.
The goal is to establish traceability:
Requirement → Obligation → Risk → Control → Owner → Implementation → Evidence → Effectiveness → Review
For a startup, this creates one practical view connecting:
Customer Requirements + Legal/Regulatory Requirements + Business Requirements + Risk → ISO 27001 Controls → Operational Implementation → Audit Evidence
Practical Principle
Know the Requirement → Understand the Obligation → Assess the Risk → Select the Control → Assign Ownership → Implement → Collect Evidence → Test Effectiveness → Review → Improve