1. Purpose
The Compliance Obligations Assessment Template provides a structured method for identifying, understanding, assessing, documenting, and monitoring the organization’s legal, regulatory, contractual, customer, industry, and other applicable compliance obligations.
The objective is to determine:
- What obligations apply to the organization
- Why they apply
- What the organization is required to do
- Which business processes are affected
- Which information and systems are affected
- Which risks arise from the obligation
- Which controls address the obligation
- What evidence demonstrates compliance
- Whether the obligation is currently satisfied
- What gaps or actions remain
Core Principle
Identify → Verify → Determine Applicability → Understand Obligation → Assess Risk → Map Controls → Assess Compliance → Address Gaps → Evidence → Approve → Monitor
2. When to Use
Use this assessment:
- When establishing or updating the ISMS
- When entering a new market or jurisdiction
- When a new law or regulation is identified
- When a regulation is amended
- When entering a new customer contract
- When customer security requirements change
- When launching a new product or service
- When processing a new category of information
- When entering a regulated industry
- When introducing new technology
- When implementing AI or generative AI
- During supplier or third-party assessments
- During internal audits
- During management review
- After significant business or technology changes
- During periodic compliance reviews
3. Assessment Information
| Field | Details |
|---|---|
| Assessment ID | |
| Assessment Date | |
| Requirement ID | |
| Requirement Type | |
| Requirement Name | |
| Jurisdiction | |
| Issuing Authority | |
| Business Owner | |
| Compliance Owner | |
| Security Reviewer | |
| Legal Reviewer | |
| Assessment Status | |
| Effective Date | |
| Next Review Date |
4. Requirement Source
Identify where the obligation originates.
☐ Law
☐ Regulation
☐ Regulatory guidance
☐ Government notification
☐ Regulatory circular
☐ Court/order requirement where applicable
☐ Contract
☐ Customer requirement
☐ Supplier requirement
☐ Industry requirement
☐ Certification requirement
☐ Internal business requirement
☐ Insurance requirement
☐ Other: ______________________
Source Details
Requirement: ______________________________
Authority/Organization: ____________________
Jurisdiction: ______________________________
Official Source: ___________________________
Publication Date: ___________________________
Effective Date: ____________________________
5. Requirement Verification
Before assessing the requirement, verify:
☐ Source is authoritative
☐ Requirement is current
☐ Publication date confirmed
☐ Effective date confirmed
☐ Jurisdiction confirmed
☐ Scope confirmed
☐ Applicable entity confirmed
☐ Relevant definitions reviewed
☐ Amendments reviewed
☐ Related guidance reviewed
☐ Applicability assumptions documented
Verification Notes
6. Requirement Classification
Classify the obligation.
| Category | Selection |
|---|---|
| Legal | ☐ |
| Regulatory | ☐ |
| Contractual | ☐ |
| Customer | ☐ |
| Privacy | ☐ |
| Cybersecurity | ☐ |
| Industry | ☐ |
| Certification | ☐ |
| Internal | ☐ |
| Other | ☐ |
Compliance Domain
☐ Information Security
☐ Privacy
☐ Cybersecurity
☐ Data Protection
☐ Cloud Security
☐ AI Security
☐ Financial Controls
☐ Business Continuity
☐ Incident Management
☐ Third-Party Risk
☐ Data Retention
☐ Data Transfer
☐ Other: ______________________
7. Applicability Assessment
Not every requirement identified during monitoring will apply to the organization.
Assess:
☐ Legal entity
☐ Jurisdiction
☐ Business location
☐ Customer location
☐ Employee location
☐ Services provided
☐ Products provided
☐ Industry
☐ Information processed
☐ Personal data processed
☐ Customer data processed
☐ Financial activity
☐ Technology used
☐ Cloud services
☐ AI services
☐ Supplier relationships
☐ Contractual commitments
Applicability Decision
☐ Applicable
☐ Potentially Applicable — Further Review Required
☐ Not Applicable
☐ Applicable With Conditions
Applicability Rationale
If the requirement is considered Not Applicable, document the reason clearly.
8. Business Context
Describe why the requirement may apply.
Business Activity
Product/Service
Customer Type
Geographic Scope
Relevant Business Process
9. Obligation Interpretation
Translate the requirement into practical obligations.
What Must the Organization Do?
What Must the Organization Not Do?
Required Activities
☐ Security control
☐ Privacy control
☐ Reporting
☐ Notification
☐ Record keeping
☐ Risk assessment
☐ Security testing
☐ Access control
☐ Data protection
☐ Retention/deletion
☐ Contractual requirement
☐ Training
☐ Monitoring
☐ Audit
☐ Business continuity
☐ Incident response
☐ Other: ______________________
10. Obligation Breakdown
Break complex requirements into individual obligations.
| Obligation ID | Obligation | Requirement | Frequency/Deadline | Owner |
|---|---|---|---|---|
| OBL-001 | ||||
| OBL-002 | ||||
| OBL-003 |
This is important because one regulation may contain multiple operational obligations.
11. Mandatory vs Guidance
Determine the nature of the requirement.
☐ Mandatory legal/regulatory requirement
☐ Contractually mandatory requirement
☐ Regulatory guidance
☐ Recommended practice
☐ Industry expectation
☐ Internal requirement
Interpretation
Guidance should not automatically be represented as a mandatory legal requirement.
12. Information Impact Assessment
Determine what information is affected.
☐ Public information
☐ Internal information
☐ Confidential information
☐ Restricted information
☐ Personal data
☐ Sensitive personal data where applicable
☐ Customer data
☐ Financial information
☐ Health information
☐ Payment information
☐ Source code
☐ Security information
☐ Credentials/secrets
☐ Intellectual property
☐ Other: ______________________
Information Description
13. Business Process Impact
Identify affected processes.
| Business Process | Impact | Process Owner |
|---|---|---|
Consider:
- Sales
- Customer onboarding
- Product development
- IT operations
- Security
- HR
- Finance
- Support
- Data processing
- Procurement
- Supplier management
- Incident management
- Business continuity
14. Technology Impact
Identify affected technology.
☐ AWS/cloud infrastructure
☐ Applications
☐ Databases
☐ APIs
☐ IAM/SSO
☐ Endpoints
☐ Network
☐ Logging/SIEM
☐ Backup
☐ CI/CD
☐ Source-code repository
☐ SaaS platforms
☐ Security tools
☐ AI systems
☐ Data-processing platforms
☐ Other: ______________________
Technology Impact
15. Security Impact Assessment
Assess impact on:
| Security Area | Impact | Existing Control |
|---|---|---|
| Confidentiality | ||
| Integrity | ||
| Availability | ||
| Access Control | ||
| Authentication | ||
| Encryption | ||
| Logging | ||
| Monitoring | ||
| Incident Management | ||
| Vulnerability Management | ||
| Business Continuity |
16. Privacy Impact Assessment
Where personal data is involved:
☐ Data collection
☐ Purpose of processing
☐ Lawful basis where applicable
☐ Data minimization
☐ Data subject rights
☐ Data retention
☐ Data deletion
☐ Data sharing
☐ Data processors
☐ Subprocessors
☐ International transfers
☐ Data security
☐ Breach notification
☐ Privacy notices
Privacy Impact
17. Contractual Impact
Determine whether the obligation affects contracts.
☐ Customer contracts
☐ MSA
☐ SOW
☐ DPA
☐ NDA
☐ Security addendum
☐ Supplier contracts
☐ SLA
☐ Insurance requirements
☐ Certification commitments
Contractual Impact
18. Customer Impact
Determine whether customer commitments are affected.
☐ Security requirements
☐ Privacy requirements
☐ Data location
☐ Data retention
☐ Data deletion
☐ Incident notification
☐ Security testing
☐ Certifications
☐ Availability
☐ Business continuity
☐ Audit rights
☐ Subprocessor requirements
Customer Impact
19. Risk Assessment
Assess risks resulting from the obligation.
| Risk ID | Risk Description | Likelihood | Impact | Risk Level | Treatment |
|---|---|---|---|---|---|
| R-001 |
Consider:
- Non-compliance
- Security exposure
- Privacy exposure
- Customer impact
- Regulatory action
- Contractual breach
- Financial impact
- Operational impact
- Reputational impact
20. Requirement-to-Control Mapping
Map each obligation to the relevant controls.
| Obligation | Risk | Control | Control Owner | Status | Evidence |
|---|---|---|---|---|---|
Controls may include:
- Existing ISO 27001 controls
- Custom organizational controls
- Technical controls
- Administrative controls
- Privacy controls
- Contractual controls
- Monitoring controls
- Business continuity controls
21. ISO/IEC 27001 Control Mapping
Where relevant, identify related ISMS controls.
| Requirement | Control Objective | ISO/IEC 27001 Control | Implementation | Evidence |
|---|---|---|---|---|
Important
Do not assume that every compliance obligation must map one-to-one to an Annex A control.
A requirement may be addressed by:
- Multiple controls
- A combination of technical and organizational measures
- A custom control
- A business process
- A contractual control
Controls should be determined through the organization’s risk assessment and applicable ISMS processes.
22. Statement of Applicability Mapping
Where relevant:
| Requirement | Control | SoA Reference | Applicable | Justification |
|---|---|---|---|---|
Requirements that require controls outside Annex A should still be addressed through appropriate organizational controls.
23. Policy Mapping
Identify relevant policies.
| Requirement | Policy | Procedure | Owner | Status |
|---|---|---|---|---|
Examples:
- Information Security Policy
- Access Control Policy
- Privacy Policy
- Incident Management Policy
- Supplier Security Policy
- Cloud Security Policy
- Business Continuity Policy
- Data Retention Policy
- AI Security Policy
24. Evidence Assessment
Determine what evidence demonstrates compliance.
☐ Policy
☐ Procedure
☐ Risk assessment
☐ Configuration
☐ Access review
☐ Security testing
☐ Audit report
☐ Training record
☐ Log
☐ Monitoring record
☐ Incident record
☐ Contract
☐ DPA
☐ Customer communication
☐ Backup evidence
☐ DR test
☐ Management review
☐ Other: ______________________
Evidence Register
| Evidence ID | Evidence | Owner | Period | Location | Status |
|---|---|---|---|---|---|
25. Evidence Quality Assessment
Evidence should be assessed for:
☐ Relevance
☐ Completeness
☐ Accuracy
☐ Authenticity
☐ Traceability
☐ Current status
☐ Appropriate retention
☐ Appropriate access protection
Evidence Quality
☐ Satisfactory
☐ Partially Satisfactory
☐ Insufficient
☐ Not Available
Evidence Gap
26. Compliance Status Assessment
Assess the current state.
| Status | Description |
|---|---|
| Compliant | Requirement is implemented and sufficient evidence exists |
| Partially Compliant | Requirement is partly implemented or evidence is incomplete |
| Non-Compliant | Requirement is not adequately addressed |
| Not Yet Assessed | Assessment is incomplete |
| Not Applicable | Requirement does not apply |
| Further Review Required | Applicability or interpretation remains uncertain |
Overall Compliance Status
☐ Compliant
☐ Partially Compliant
☐ Non-Compliant
☐ Not Yet Assessed
☐ Further Review Required
☐ Not Applicable
27. Gap Assessment
Identify gaps between the obligation and current implementation.
| Gap ID | Requirement | Current State | Required State | Gap | Risk | Owner |
|---|---|---|---|---|---|---|
| GAP-001 |
28. Remediation / Corrective Action
For each significant gap:
| Action ID | Gap | Corrective Action | Owner | Priority | Due Date | Status |
|---|---|---|---|---|---|---|
| CA-001 |
Actions should be tracked through the organization’s Corrective Action Tracker where appropriate.
29. Compliance Deadline Assessment
Determine whether the requirement has a specific deadline.
Effective Date: __________________
Compliance Deadline: ______________
Notification Deadline: _____________
Reporting Frequency: ______________
Renewal/Review Date: ______________
Deadline Risk
☐ No deadline identified
☐ Adequate time available
☐ Tight implementation period
☐ Immediate action required
Do not assume a universal regulatory deadline. Record the deadline applicable to the specific requirement.
30. Compliance Implementation Plan
For significant requirements:
| Action | Owner | Start Date | Due Date | Evidence | Status |
|---|---|---|---|---|---|
Implementation may require:
- Policy changes
- Technical changes
- Process changes
- Contract changes
- Training
- New monitoring
- Security testing
- Risk treatment
- Supplier changes
- Customer communication
31. Compliance Exception
If the organization cannot currently meet an obligation:
☐ Exception required
☐ Risk acceptance required
☐ Compensating control required
☐ Legal review required
☐ Customer approval required
☐ Management approval required
Exception Description
Compensating Controls
Residual Risk
Expiry/Review Date
Exceptions should not be treated as permanent alternatives to compliance without appropriate authorization and risk assessment.
32. Compliance Assessment Decision
Assessment Result
☐ Compliant
☐ Compliant With Conditions
☐ Partially Compliant
☐ Remediation Required
☐ Risk Acceptance Required
☐ Further Legal/Regulatory Review Required
☐ Not Applicable
Decision Rationale
33. Management Review
Significant compliance obligations should be communicated to appropriate management.
Management Considerations
☐ Compliance status
☐ Open gaps
☐ Regulatory risk
☐ Customer impact
☐ Financial impact
☐ Security impact
☐ Privacy impact
☐ Required resources
☐ Implementation deadline
☐ Residual risk
☐ Risk acceptance
Management Decision
34. Assessment Approval
Assessment Owner: __________________________
Compliance Owner: __________________________
Security Reviewer: __________________________
Legal Reviewer: _____________________________
Business Owner: _____________________________
Risk Owner: _________________________________
Approver: ___________________________________
Assessment Date: ____________________________
Next Review Date: ___________________________
35. Periodic Reassessment
The obligation should be reassessed when:
☐ Regulation changes
☐ New guidance is issued
☐ Business model changes
☐ New jurisdiction entered
☐ New product launched
☐ New customer type introduced
☐ New information category processed
☐ New technology introduced
☐ New AI capability introduced
☐ Major supplier changes
☐ Customer contract changes
☐ Security incident occurs
☐ Audit identifies a gap
☐ Regulatory enforcement changes
☐ Significant organizational change
36. Compliance Obligation Register
Maintain a central register containing:
| Obligation ID | Requirement | Source | Jurisdiction | Applicable | Owner | Control | Status | Risk | Next Review |
|---|---|---|---|---|---|---|---|---|---|
| OBL-001 |
The register should provide a consolidated view of the organization’s compliance obligations.
37. Compliance Assessment Summary
| Area | Result | Key Finding | Risk | Action |
|---|---|---|---|---|
| Applicability | ||||
| Legal/Regulatory | ||||
| Security | ||||
| Privacy | ||||
| Contractual | ||||
| Customer | ||||
| Technology | ||||
| Business Continuity | ||||
| Evidence | ||||
| Overall Compliance |
38. AWS SaaS Startup Example
Consider a SaaS company operating on AWS and serving customers in multiple jurisdictions.
A new privacy/security requirement is identified.
Step 1 — Identify
The requirement is recorded in the regulatory monitoring process.
Step 2 — Verify
The organization verifies:
- Official source
- Jurisdiction
- Effective date
- Applicability
- Relevant obligations
Step 3 — Assess
The assessment identifies impact on:
- Customer data
- AWS production environment
- Data retention
- Incident management
- Access control
- Security monitoring
Step 4 — Map
The obligations are mapped to:
Requirement → Risk → Control → Policy → Evidence
Example:
| Obligation | Risk | Control | Evidence |
|---|---|---|---|
| Protect customer data | Unauthorized disclosure | Encryption + access control | AWS configuration/evidence |
| Restrict access | Unauthorized access | IAM + MFA + least privilege | Access review |
| Detect incidents | Delayed response | Logging + monitoring | Cloud/security logs |
| Respond to incidents | Regulatory exposure | Incident response procedure | Incident records |
| Retain information appropriately | Excessive retention | Retention controls | Retention records |
Step 5 — Gap Assessment
The organization identifies that its data-retention process does not fully address the new requirement.
Step 6 — Corrective Action
A corrective action is created:
Update retention schedule → Configure applicable systems → Validate deletion → Collect evidence → Review effectiveness.
Step 7 — Closure
The obligation is not marked compliant until the implementation has been validated and evidence is available.
39. Startup-Friendly Assessment Model
A startup can simplify the assessment into ten questions:
- What requirement are we assessing?
- Where does it come from?
- Does it actually apply to us?
- What exactly are we required to do?
- What information or business process is affected?
- What risk exists if we do not meet it?
- Which controls address the obligation?
- What evidence proves the controls work?
- Are there any gaps or exceptions?
- Who approved the assessment and when is it reviewed again?
If these questions can be answered consistently, the organization has a defensible compliance assessment process.
40. Common Mistakes
Avoid:
- Treating every law or regulation as automatically applicable.
- Copying regulatory text without understanding the actual obligation.
- Relying only on compliance checklists.
- Failing to identify the effective date.
- Confusing guidance with mandatory requirements.
- Mapping a requirement to a control without testing the control.
- Treating ISO 27001 certification as proof of compliance with every regulation.
- Ignoring contractual obligations.
- Ignoring customer-specific requirements.
- Failing to assess privacy implications.
- Closing gaps without evidence.
- Treating policy existence as proof of operational compliance.
- Failing to document non-applicability decisions.
- Leaving compliance ownership unclear.
- Accepting exceptions without documented risk assessment and approval.
41. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Legal & Regulatory Requirements Register | Identifies applicable requirements |
| Regulatory Monitoring Procedure | Identifies regulatory changes |
| Regulatory Monitoring Register | Tracks regulatory changes |
| Contractual Security Requirements Register | Tracks contractual obligations |
| Requirement-to-Control Mapping Matrix | Maps obligations to controls |
| Risk Register | Tracks compliance-related risks |
| Statement of Applicability | Records applicable ISMS controls |
| Corrective Action Tracker | Tracks remediation |
| Compliance Obligations Assessment | Assesses individual obligations |
| Internal Audit | Independently evaluates implementation |
| Management Review | Provides management oversight |
| ISMS Improvement Log | Tracks improvements |
42. ISO/IEC 27001 Connection
A compliance obligations assessment supports the organization’s risk-based ISMS by helping it understand external and internal requirements relevant to information security.
The assessment can support:
- Context of the organization
- Interested-party requirements
- Information-security risk assessment
- Risk treatment
- Control selection
- Statement of Applicability
- Operational control implementation
- Monitoring and measurement
- Internal audit
- Management review
- Continual improvement
ISO/IEC 27001 does not prescribe this exact assessment template.
The organization should determine the appropriate compliance-assessment process based on its:
- Legal requirements
- Regulatory environment
- Contracts
- Customer requirements
- Business context
- Information-security risks
- Industry
- Jurisdictions
43. Audit Evidence
For each significant obligation, retain appropriate evidence such as:
- Requirement source
- Applicability assessment
- Legal/compliance interpretation
- Risk assessment
- Requirement-to-control mapping
- Policy mapping
- Control evidence
- Testing evidence
- Compliance assessment
- Gap register
- Corrective actions
- Exception/risk acceptance
- Management approval
- Periodic review
The evidence should allow an auditor to trace:
Requirement → Applicability → Obligation → Risk → Control → Implementation → Evidence → Assessment → Decision
44. Final Compliance Assessment Audit Trail
For every significant compliance obligation, the organization should be able to demonstrate:
Requirement Identified
↓
Source Verified
↓
Jurisdiction Confirmed
↓
Applicability Assessed
↓
Obligation Understood
↓
Business/Information/Technology Impact Assessed
↓
Risk Assessed
↓
Controls Identified
↓
Requirement-to-Control Mapping Completed
↓
Evidence Identified
↓
Compliance Status Assessed
↓
Gaps Identified
↓
Corrective Actions Assigned
↓
Controls Implemented
↓
Effectiveness/Evidence Validated
↓
Residual Risk Assessed
↓
Approval Recorded
↓
Requirement Monitored and Reassessed
45. Final Principle
Compliance is not simply knowing which regulations exist.
An effective compliance obligations assessment connects the external requirement to the organization’s actual business, information, technology, risks, controls, evidence, and ownership.
Final Principle
Know the Requirement → Confirm It Applies → Understand the Obligation → Assess the Risk → Map the Control → Implement → Collect Evidence → Test → Assess Compliance → Address Gaps → Approve → Monitor → Improve