Legal & Regulatory Requirements Register

1. Purpose

The Legal & Regulatory Requirements Register is a central record used to identify, assess, monitor, and maintain the legal, regulatory, contractual, and other applicable requirements that may affect the organization’s information security and business operations.

The register helps the organization answer:

What legal, regulatory, contractual, and other requirements apply to us, what do they require, who owns them, how are we complying, and what evidence demonstrates compliance?

The register should be maintained as a living document and reviewed when laws, regulations, business activities, customers, technology, or organizational scope changes.

2. Scope

The register may cover requirements relating to:

Information security
Data protection and privacy
Personal data
Customer data
Financial information
Employee information
Intellectual property
Cybersecurity
Cloud services
Electronic records
Communications
Payment processing
Industry-specific regulations
Employment-related requirements
Tax and corporate requirements where relevant to the ISMS
Customer and contractual security requirements
Regulatory reporting
Records retention
Incident and breach notification
Cross-border data transfers
Third-party and supplier requirements
Certification and customer commitments

Not every legal requirement applicable to the organization needs to become an ISO 27001 control. The organization should determine which requirements are relevant to its ISMS and information security risks.

3. Types of Requirements

Requirements may originate from several sources.

Requirement Type	Example
Law	Data protection legislation
Regulation	Financial-sector cybersecurity regulation
Government requirement	Regulatory reporting requirement
Contract	Customer security obligations
DPA	Data processing requirements
NDA	Confidentiality obligations
Customer requirement	SOC 2 or ISO 27001 requirement in contract
Industry requirement	PCI DSS
Certification requirement	ISO/IEC 27001 certification obligations
Court/legal requirement	Legal preservation or disclosure
Internal requirement	Security commitments approved by management

4. Legal & Regulatory Requirement Identification

The organization should identify requirements relevant to:

Business

Countries where the organization operates
Countries where customers are located
Countries where employees or contractors are located
Products and services offered
Industries served
Business processes
Data processed
Technology used
Cloud services
Payment services

Information

Personal data
Customer information
Employee information
Financial information
Health information
Confidential information
Intellectual property
Source code
Authentication information
Security logs
Business records

Technology

Cloud platforms
SaaS applications
Databases
APIs
Production systems
Email
Identity platforms
Backup systems
Security monitoring systems

5. Requirement Register

The following is the recommended master register.

Requirement ID	Requirement	Type	Jurisdiction	Applies?	Business Area	Information/System	Owner	Status	Evidence	Review Date
LR-001	Applicable data protection law	Legal	India	Yes	Customer Operations	Customer Data	Privacy Owner	Compliant	Privacy Policy, DPA	2027-01-01
LR-002	Customer contractual security requirements	Contract	USA	Yes	SaaS	Production Data	Security Lead	Active	Contract	2027-01-01
LR-003	PCI DSS	Industry	Applicable scope	No	Payments	Payment Data	Compliance	N/A	Scope Assessment	2027-01-01

6. Requirement Identification Record

Each requirement should have sufficient information to understand what it means for the organization.

Requirement Details

Requirement ID:
Requirement Name:
Requirement Type:
Jurisdiction:
Regulator / Authority:
Source / Reference:
Effective Date:
Last Reviewed:
Next Review:

Applicability

Applicable to Organization: Yes / No / Partially

Reason for Applicability:

Business Process Affected:

Information Affected:

Systems / Technology Affected:

Customers / Third Parties Affected:

7. Requirement Description

Document the requirement in practical terms.

Example

Instead of simply recording:

Data protection law

record:

The organization processes personal information relating to customers and employees and must apply appropriate privacy, security, retention, access, and data-handling requirements applicable to its processing activities.

The register should explain what the organization actually needs to do.

8. Compliance Obligation

For every applicable requirement, identify the specific obligation.

Examples:

Protect personal information
Restrict unauthorized access
Maintain appropriate security measures
Maintain records
Provide privacy notices
Manage data processors
Control data retention
Respond to applicable data-subject requests
Report qualifying incidents where required
Maintain contractual security controls
Protect confidential information
Maintain required records
Perform required assessments
Maintain evidence of compliance

9. Requirement-to-Control Mapping

Legal and regulatory requirements should be mapped to the organization’s policies, procedures, controls, and operational activities.

Requirement	Obligation	Internal Control	Owner	Evidence
Data protection requirement	Protect personal data	Access Control	IT/Security	Access review
Data protection requirement	Control retention	Data Retention Procedure	Privacy	Retention record
Customer contract	Security controls	ISMS Security Controls	Security	Audit evidence
Payment requirement	Protect payment information	Payment Security Controls	IT	Security assessment

This mapping makes the register useful during internal and external audits.

10. Applicable Policies and Procedures

Identify internal documents supporting each requirement.

Examples:

Information Security Policy
Access Control Policy
Data Classification Policy
Data Protection Policy
Privacy Policy
Incident Response Procedure
Data Breach Procedure
Backup and Recovery Procedure
Supplier Security Policy
Cloud Security Policy
Records Retention Procedure
Business Continuity Plan
Disaster Recovery Plan
Acceptable Use Policy
Secure Development Procedure

11. Evidence Requirements

The organization should identify evidence that demonstrates the requirement is being addressed.

Possible evidence includes:

Policies
Procedures
Risk assessments
Access reviews
Training records
Incident records
Data inventories
RoPA where applicable
Contracts
DPAs
Supplier assessments
Audit reports
Vulnerability assessments
Penetration testing reports
Security configuration records
Backup records
Recovery test results
Incident notification assessments
Management review records
Internal audit reports
Corrective action records

12. Compliance Status

Use consistent status values.

Status	Meaning
Not Assessed	Requirement has not yet been evaluated
Applicable – Gap Identified	Requirement applies and a gap exists
Partially Compliant	Some requirements implemented
Compliant	Requirement addressed with supporting evidence
Not Applicable	Requirement does not apply
Under Review	Applicability or interpretation is being assessed
Remediation in Progress	Corrective actions underway
Monitoring	Requirement implemented and being monitored

A status of Compliant should be supported by objective evidence.

13. Compliance Gap Assessment

Where a requirement is not fully addressed, record the gap.

Requirement	Gap	Risk	Action	Owner	Target Date	Status
Privacy requirement	Retention process not formally documented	Medium	Implement retention procedure	Privacy Owner	2027-02-15	Open

The gap should be linked to the organization’s:

Risk Register
Corrective Action Tracker
ISMS Improvement Log

where appropriate.

14. Requirement Risk Assessment

Not every requirement has the same business impact.

Consider:

Regulatory penalties
Contractual consequences
Customer impact
Personal data impact
Financial impact
Business interruption
Legal exposure
Reputation
Information security impact
Certification impact

Example

A requirement involving sensitive customer information may receive a higher priority than a low-impact administrative requirement.

15. Contractual Requirements

Legal and regulatory registers should not focus only on legislation.

Customer contracts can create significant information-security obligations.

Examples:

SOC 2 requirement
ISO 27001 requirement
Customer security questionnaire commitments
Encryption requirements
Breach notification timelines
Vulnerability management requirements
Security audit rights
Data-location requirements
Subprocessor notification
Business continuity requirements
Data deletion requirements
Security incident notification

Contractual requirements should be recorded and monitored in the same controlled manner.

16. Customer Security Commitments

For SaaS organizations, maintain a separate mapping where necessary.

Customer	Requirement	Contract Clause	Owner	Evidence	Review
Customer A	SOC 2 Type II	Section 8	Security	SOC 2 Report	Annual
Customer B	Incident notification	Section 12	Security/Legal	Incident Procedure	Annual

This prevents important customer commitments from being lost inside contracts.

17. Regulatory Change Monitoring

The organization should establish a method for identifying changes to applicable requirements.

Possible sources include:

Government websites
Regulators
Industry bodies
Legal counsel
Privacy counsel
Compliance advisors
Certification bodies
Customer notifications
Professional associations
Regulatory newsletters

Record significant changes.

Date	Requirement	Change Identified	Impact	Action	Owner
2027-01-10	Privacy requirement	Regulatory update	Medium	Review privacy controls	Privacy Owner

18. Change Assessment

When a legal or regulatory requirement changes, assess:

What changed?
Does it apply to the organization?
Which business processes are affected?
Which information is affected?
Which systems are affected?
Which policies need updating?
Which controls need changing?
Is a new risk created?
Are contracts affected?
Is customer communication required?
Is training required?
Is evidence required?
Is management approval required?

19. Legal & Regulatory Requirement Review

Review the register periodically and whenever significant changes occur.

Review triggers may include:

New law or regulation
Regulatory amendment
New country
New customer market
New product
New service
New type of data
New supplier
New cloud service
Acquisition or merger
Major technology change
Security incident
Audit finding
Customer contractual change
Business restructuring

20. AWS SaaS Startup Example

Consider a SaaS startup operating:

AWS production environment
Customer database
S3 storage
ECS workloads
RDS database
CloudFront/WAF
IAM/SSO
Customer support platform
CRM
Payment provider

The organization may identify requirements related to:

Area	Requirement Consideration	Impact
Customer Data	Data protection requirements	High
Employee Data	Employment/privacy requirements	Medium
AWS	Customer contractual security requirements	High
Payment	Payment security requirements if applicable	High
Incident	Contractual/regulatory notification	High
Backup	Contractual/recovery obligations	Medium/High
Supplier	DPA/security requirements	High
Data Transfer	Cross-border requirements where applicable	High
Retention	Legal/contractual retention	Medium
Confidentiality	NDA/customer contracts	High

The startup should not assume that every regulation listed online applies to it.

Applicability should be determined from its actual business model, geography, customers, data, services, and contractual commitments.

21. Legal & Regulatory Requirement Assessment Questions

For every new requirement, ask:

Applicability

Does this requirement apply to us?
Why does it apply?
Which jurisdiction applies?
Which business activity triggers it?

Information

What information is affected?
Is personal data involved?
Is regulated or sensitive information involved?

Operations

Which process is affected?
Which employees or teams are involved?
Which suppliers are involved?

Technology

Which systems process the information?
Which cloud services are involved?
Which applications or databases are affected?

Compliance

What exactly must we do?
What evidence demonstrates compliance?
Who owns the requirement?
How often should it be reviewed?

Change

How will we know when the requirement changes?
What happens if the requirement changes?

22. Legal & Regulatory Requirements Register — Minimum Fields

A startup can begin with the following minimum fields:

Field
Requirement ID
Requirement Name
Requirement Type
Jurisdiction
Authority/Source
Applicability
Applicability Reason
Obligation
Business Process
Information/System
Requirement Owner
Related Policy/Control
Evidence
Compliance Status
Gap
Risk
Corrective Action
Target Date
Last Review
Next Review

As the ISMS matures, additional fields can be added.

23. Relationship With Other ISMS Records

The Legal & Regulatory Requirements Register should not operate independently.

A practical relationship is:

Business Context

↓

Legal / Regulatory / Contractual Requirements

↓

Applicability Assessment

↓

Compliance Obligations

↓

Risk Assessment

↓

Control Requirements

↓

Policies & Procedures

↓

Implementation

↓

Evidence

↓

Internal Audit

↓

Corrective Action

↓

Management Review

↓

Continual Improvement

24. Relationship With Risk Assessment

A legal or regulatory requirement may create information-security risk.

For example:

Requirement: Protect customer personal information

→ Information identified

→ Threat identified

→ Unauthorized access risk identified

→ Risk assessed

→ Controls selected

→ Access control implemented

→ Access reviews performed

→ Evidence collected

→ Residual risk assessed

This creates a defensible connection between legal obligations and the ISMS risk-management process.

25. Relationship With Statement of Applicability

The register can also support the Statement of Applicability (SoA).

For example:

Legal requirement

→ identifies security obligation

→ risk assessment

→ required security control

→ Annex A comparison

→ SoA applicability decision

→ implementation

→ evidence

The organization should not select Annex A controls merely because they appear in the register.

Controls should be determined through the organization’s risk treatment and applicable requirements, with Annex A used as a reference/comparison mechanism.

26. Management Review

Significant legal and regulatory changes should be considered during management review where relevant.

Management may review:

New requirements
Regulatory changes
Compliance gaps
Overdue actions
Significant contractual commitments
Regulatory incidents
Customer security requirements
Compliance risks
Resource requirements
Changes requiring ISMS improvement

27. Startup Implementation

A startup does not need an enormous legal database to begin.

Start with:

Step 1 — Identify

List the countries, customers, services, data, and industries relevant to the organization.

Step 2 — Determine Applicability

For each potential requirement, record:

Applicable / Not Applicable / Under Review

Step 3 — Identify Obligations

Convert the requirement into practical actions.

Step 4 — Assign Owners

Every applicable requirement should have an accountable owner.

Step 5 — Map Controls

Connect the requirement to policies, procedures, controls, and operational activities.

Step 6 — Identify Evidence

Determine what proves the requirement is being addressed.

Step 7 — Identify Gaps

Record deficiencies and link them to risk/corrective actions.

Step 8 — Monitor Changes

Review relevant legal and regulatory sources periodically.

Step 9 — Review

Update the register after significant business, technology, regulatory, or contractual changes.

28. Common Mistakes

Mistake 1 — Copying a list of regulations from the internet

A regulation is not automatically applicable just because it exists.

Mistake 2 — No applicability rationale

Record why something applies or does not apply.

Mistake 3 — Recording only the law name

The register should explain the practical obligation.

Mistake 4 — No owner

Every applicable requirement should have ownership.

Mistake 5 — No evidence

A compliance statement without supporting evidence is difficult to defend during an audit.

Mistake 6 — Ignoring contracts

Customer contracts can create significant security obligations.

Mistake 7 — Never reviewing the register

Legal and regulatory requirements can change.

Mistake 8 — Treating compliance as an IT-only responsibility

Legal, privacy, security, HR, finance, business, procurement, and management may all have responsibilities.

Mistake 9 — Automatically declaring “Compliant”

Compliance status should be supported by objective evidence.

Mistake 10 — Creating a register disconnected from the ISMS

The register should connect requirements to risk, controls, evidence, audit, corrective actions, and management review.

29. Audit Evidence

An auditor may expect to see evidence that the organization has identified and considered applicable requirements.

Useful evidence includes:

Legal & Regulatory Requirements Register
Applicability assessments
Contract reviews
Customer security requirements
DPAs
Privacy assessments
Regulatory monitoring records
Compliance assessments
Policies and procedures
Risk assessments
SoA mapping
Internal audit records
Corrective actions
Management review records
Regulatory change assessments

The objective is not simply to show a spreadsheet.

The objective is to demonstrate that the organization understands its obligations and manages them systematically.

30. Final Audit Trail

A strong Legal & Regulatory Requirements process should demonstrate:

Requirement Identified

→ Source Verified

→ Applicability Assessed

→ Obligation Identified

→ Owner Assigned

→ Risk/Impact Assessed

→ Controls Identified

→ Policy/Procedure Mapped

→ Evidence Identified

→ Compliance Status Determined

→ Gap Identified Where Applicable

→ Corrective Action Assigned

→ Requirement Changes Monitored

→ Periodic Review Completed

→ Management Review Where Required

→ ISMS Updated Where Necessary

31. ISO/IEC 27001 Alignment

The register supports the ISMS by providing a structured mechanism for identifying and managing applicable legal, regulatory, contractual, and other requirements.

It can support:

ISMS context and interested-party requirements
Information security risk assessment
Risk treatment
Applicable security controls
Statement of Applicability
Operational control
Documented information
Internal audit
Management review
Corrective action
Continual improvement

The exact legal and regulatory requirements applicable to an organization depend on its jurisdiction, business model, information processed, customers, services, contracts, and risk environment.

32. Final Principle

A Legal & Regulatory Requirements Register is not simply a list of laws. It is the organization’s controlled record of what requirements apply, what those requirements mean for the business, who owns them, how they are addressed, and what evidence demonstrates compliance.

The practical chain is:

Identify → Verify → Assess Applicability → Understand Obligation → Assign Ownership → Map Controls → Collect Evidence → Assess Compliance → Address Gaps → Monitor Changes → Review → Improve

For a startup, the goal is not to create a huge compliance spreadsheet.

The goal is to ensure that no important legal, regulatory, contractual, or customer security obligation is unknown, unmanaged, or unsupported by evidence.