1. Purpose

The Customer Contract Security Review Checklist provides a structured method for reviewing customer contracts, agreements, statements of work, security schedules, DPAs, SLAs, and related documents for information-security, privacy, compliance, business continuity, and operational commitments.

The objective is to identify security obligations before the organization commits to them and determine whether those obligations can be implemented, monitored, evidenced, and maintained.

The checklist helps answer:

What security commitments is the customer asking us to make, can we meet them, who owns them, and what evidence will demonstrate compliance?

---

2. When to Use

Use this checklist:

• Before signing a new customer contract
• Before signing a security addendum
• Before accepting a customer DPA
• Before accepting a customer SLA
• Before responding to customer security requirements
• During contract renewal
• When a contract is materially amended
• When a customer introduces new security requirements
• When service scope changes
• When new customer data is introduced
• When new countries or jurisdictions are involved
• When production access requirements change
• When customer requirements affect the ISMS

---

3. Documents to Review

Collect all relevant contractual documents.

☐ Master Service Agreement (MSA)
☐ Order Form
☐ Statement of Work (SOW)
☐ Service Level Agreement (SLA)
☐ Data Processing Agreement (DPA)
☐ Security Addendum
☐ Information Security Schedule
☐ Privacy Schedule
☐ Business Continuity Schedule
☐ Customer Security Requirements
☐ Customer Questionnaire
☐ Customer Policies incorporated by reference
☐ Technical Requirements
☐ Service Description
☐ Other: __________________________

Do not review the security section in isolation. Security obligations may appear elsewhere in the contract.

---

4. Contract Identification

Field	Details
Contract ID
Customer
Contract Type
Product/Service
Business Owner
Account Owner
Legal Reviewer
Security Reviewer
Privacy Reviewer
Technical Reviewer
Contract Start Date
Contract End Date
Renewal Date
Review Date
Version Reviewed

---

5. Customer and Service Assessment

Understand the relationship before reviewing individual clauses.

Customer

☐ Customer identified
☐ Customer industry identified
☐ Customer location identified
☐ Customer regulatory environment understood
☐ Customer criticality assessed
☐ Customer requirements understood

Service

☐ Service clearly defined
☐ Service scope understood
☐ Customer-facing components identified
☐ Production environment identified
☐ Support model understood
☐ Customer data identified
☐ Personal data identified
☐ Critical dependencies identified

Business Impact

☐ Customer is strategically important
☐ Service is business-critical
☐ Significant revenue dependency identified
☐ High customer concentration identified
☐ Special contractual obligations identified

---

6. Information Security Scope

Identify what information the customer will provide or what information the organization will generate.

☐ Customer personal data
☐ Employee data
☐ Financial information
☐ Payment information
☐ Health information
☐ Confidential information
☐ Restricted information
☐ Source code
☐ Credentials
☐ Security information
☐ Business records
☐ Intellectual property
☐ Production data
☐ Other: __________________

Highest Classification

☐ Public
☐ Internal
☐ Confidential
☐ Restricted

Classification Rationale

---

7. Data Processing Review

If customer data is processed:

☐ Data categories identified
☐ Data subjects identified
☐ Processing purpose understood
☐ Processing activities understood
☐ Controller/processor roles identified
☐ Processing locations identified
☐ Subprocessors identified
☐ Data retention requirements identified
☐ Data deletion requirements identified
☐ Data return requirements identified
☐ International transfer requirements identified
☐ Security requirements identified
☐ Data breach obligations identified

---

8. Confidentiality Requirements

Review confidentiality obligations.

☐ Confidential information defined
☐ Permitted use defined
☐ Disclosure restrictions defined
☐ Employee/contractor access addressed
☐ Supplier access addressed
☐ Subprocessor requirements addressed
☐ Confidentiality survives termination where required
☐ Exceptions understood
☐ Disclosure required by law addressed
☐ Secure disposal addressed

Security Consideration

Determine whether the confidentiality requirement requires additional technical or organizational controls.

---

9. Information Security Requirements

Identify explicit security commitments.

☐ Information-security program
☐ Security policies
☐ Security governance
☐ Risk management
☐ Security awareness
☐ Security personnel
☐ Security monitoring
☐ Security testing
☐ Security assessments
☐ Security certifications
☐ Security reporting
☐ Security metrics

Record every material commitment in the Contractual Security Requirements Register.

---

10. ISO 27001 Requirements

Determine whether the customer requires:

☐ ISO/IEC 27001 certification
☐ ISO/IEC 27001-aligned controls
☐ Current certificate
☐ Certification for specific scope
☐ Annual certification evidence
☐ Surveillance audit evidence
☐ Access to certification documentation
☐ Notification of certification status changes

Important

Verify that the organization’s actual certification scope covers the service being provided.

Do not promise certification for a service or environment that is outside the certification scope.

---

11. SOC 2 Requirements

Determine whether the customer requires:

☐ SOC 2 Type I
☐ SOC 2 Type II
☐ Specific Trust Services Criteria
☐ Annual report
☐ Independent assurance
☐ Bridge letter
☐ Report sharing
☐ Notification of significant exceptions

Review

☐ Requirement is achievable
☐ Report scope matches service
☐ Reporting period understood
☐ Evidence availability confirmed

---

12. Security Questionnaire Commitments

Customers may provide security questionnaires separately from the contract.

Review whether questionnaire answers become contractual commitments.

☐ Questionnaire reviewed
☐ Responses reviewed by Security
☐ Technical responses validated
☐ Legal reviewed contractual implications
☐ Unsupported claims identified
☐ Future commitments identified
☐ Exceptions documented
☐ Final response approved
☐ Questionnaire linked to contract record

Important

Do not make security claims simply because they appear desirable to the customer.

Responses should accurately reflect the organization’s actual controls.

---

13. Access Control Requirements

Review requirements concerning access to customer information or systems.

☐ Named accounts
☐ MFA
☐ Least privilege
☐ Privileged access controls
☐ Access approval
☐ Access reviews
☐ Production access restrictions
☐ Remote access restrictions
☐ Customer approval for access
☐ Background checks
☐ Access termination
☐ Temporary access
☐ Session monitoring

---

14. Customer System Access

If the customer gives the organization access to customer systems:

System	Environment	Access	Privileged	MFA	Owner

Verify:

☐ Access method defined
☐ Authentication defined
☐ MFA available
☐ Access scope defined
☐ Access approval defined
☐ Logging available
☐ Access review defined
☐ Termination process defined

---

15. Encryption Requirements

Review requirements for:

Data in Transit

☐ TLS
☐ Approved protocols
☐ Secure transfer mechanism

Data at Rest

☐ Database encryption
☐ Storage encryption
☐ Backup encryption

Key Management

☐ Key ownership
☐ Key management
☐ Key rotation
☐ Customer-managed keys
☐ Key access restrictions
☐ Key compromise requirements

---

16. Data Location Requirements

Determine whether the customer restricts where information may be:

• Stored
• Processed
• Backed up
• Transferred

Data	Location	Processing	Backup	Contract Requirement
Customer data
Personal data

Verify:

☐ Geography understood
☐ Cloud regions identified
☐ Backup locations identified
☐ Support access locations identified
☐ International transfers assessed
☐ Contract restrictions achievable

---

17. Subprocessor Requirements

Review whether the customer requires:

☐ Subprocessor disclosure
☐ Customer approval
☐ Notification of new subprocessors
☐ Subprocessor security assessment
☐ Flow-down security requirements
☐ Data-location restrictions
☐ Incident notification
☐ Subprocessor removal/change process

Subprocessor Register

The contract should be mapped to the organization’s Subprocessor Register where applicable.

---

18. Vulnerability Management

Review customer requirements concerning vulnerabilities.

☐ Vulnerability scanning
☐ Vulnerability remediation
☐ Critical vulnerability timelines
☐ High vulnerability timelines
☐ Vulnerability disclosure
☐ Customer notification
☐ Patch management
☐ Emergency remediation
☐ Vulnerability reporting

Record contractual deadlines separately from internal targets where they differ.

---

19. Penetration Testing and Security Testing

Review requirements for:

☐ Annual penetration testing
☐ Application testing
☐ Infrastructure testing
☐ Cloud security testing
☐ API testing
☐ External testing
☐ Internal testing
☐ Independent testing
☐ Customer testing rights
☐ Testing reports
☐ Remediation requirements

Testing Feasibility

☐ Scope achievable
☐ Testing frequency achievable
☐ Environment available
☐ Customer notification requirements understood
☐ Production testing restrictions understood
☐ Evidence can be provided

---

20. Secure Development Requirements

For software/SaaS services, assess:

☐ Secure SDLC
☐ Secure coding
☐ Code review
☐ Dependency management
☐ SAST
☐ DAST
☐ Software composition analysis
☐ Security testing
☐ Vulnerability remediation
☐ Change management
☐ Release controls
☐ Source-code protection

---

21. Logging and Monitoring

Review requirements for:

☐ Security logging
☐ Authentication logging
☐ Privileged activity logging
☐ Administrative activity
☐ Data access logging
☐ Cloud logging
☐ Application logging
☐ Monitoring
☐ Alerting
☐ Log retention
☐ Customer access to logs

Verify that contractual retention requirements are technically achievable.

---

22. Security Incident Requirements

Review the complete incident lifecycle.

☐ Incident definition
☐ Security event definition
☐ Qualifying incident definition
☐ Incident escalation
☐ Customer notification
☐ Notification timeframe
☐ Notification method
☐ Required notification information
☐ Incident updates
☐ Root cause analysis
☐ Corrective actions
☐ Evidence preservation
☐ Customer cooperation
☐ Regulatory coordination

---

23. Incident Notification Timeline

Record the actual contractual requirement.

Customer	Trigger	Notification Deadline	Channel	Owner

Also verify:

☐ Internal escalation can meet contractual deadline
☐ Security team knows requirement
☐ Legal/Privacy involvement defined
☐ Customer contacts recorded
☐ Out-of-band communication available if needed

---

24. Data Breach Requirements

If personal data or regulated data is involved:

☐ Breach definition reviewed
☐ Notification trigger defined
☐ Customer notification requirement defined
☐ Regulatory notification responsibility defined
☐ Data-subject communication responsibility defined
☐ Investigation cooperation defined
☐ Evidence preservation defined
☐ Root cause requirements defined
☐ Corrective action requirements defined

Do not assume every security incident is automatically a personal-data breach.

---

25. Business Continuity Requirements

Review requirements for:

☐ Business Continuity Plan
☐ Disaster Recovery Plan
☐ Backup
☐ Recovery testing
☐ Redundancy
☐ Alternate environment
☐ Availability
☐ Crisis management
☐ Customer communication
☐ Critical supplier continuity

---

26. RTO and RPO Requirements

Record contractual recovery commitments.

Service	Contract RTO	Internal RTO	Contract RPO	Internal RPO	Feasible?
Production SaaS
Customer Database

Review

☐ Requirement understood
☐ BIA reviewed
☐ Recovery capability reviewed
☐ Backup capability reviewed
☐ DR capability tested
☐ Supplier dependencies considered
☐ Contractual requirement achievable

Never commit to an RTO/RPO that has not been evaluated against actual recovery capability.

---

27. Availability Requirements

Review:

☐ Availability percentage
☐ Measurement period
☐ Planned maintenance exclusions
☐ Incident exclusions
☐ Service credits
☐ Reporting
☐ Monitoring
☐ Escalation
☐ Customer notification

Availability commitments should be reviewed with the technical and business teams before acceptance.

---

28. Backup Requirements

Review:

☐ Backup frequency
☐ Backup retention
☐ Backup encryption
☐ Backup location
☐ Backup independence
☐ Backup immutability
☐ Restore testing
☐ Customer backup requirements
☐ Backup deletion requirements

Verify that the organization’s Backup & Restore Procedure can satisfy the contractual obligation.

---

29. Disaster Recovery Testing

If testing is contractually required:

☐ Frequency identified
☐ Test scope identified
☐ Test scenario identified
☐ Customer participation identified
☐ Evidence requirements identified
☐ Reporting requirement identified
☐ Corrective-action requirement identified

Map to:

DR Test Plan → DR Test Report → Corrective Action Tracker

---

30. Data Retention

Review:

☐ Customer-defined retention
☐ Legal retention
☐ Regulatory retention
☐ Backup retention
☐ Security log retention
☐ Data deletion timing
☐ Legal hold requirements
☐ Retention exceptions

Identify conflicts between contractual deletion requirements and applicable legal/regulatory retention obligations.

---

31. Data Deletion and Return

At termination or expiration:

☐ Data return required
☐ Data export format defined
☐ Deletion required
☐ Backup deletion addressed
☐ Subprocessor deletion addressed
☐ Deletion timeframe defined
☐ Deletion evidence required
☐ Certificate of destruction required
☐ Legal hold exception addressed

Map to the organization’s Supplier/Customer Offboarding or Data Disposal process, as applicable.

---

32. Customer Audit Rights

Review whether the customer can:

☐ Request security evidence
☐ Conduct questionnaires
☐ Conduct remote audits
☐ Conduct on-site audits
☐ Request penetration-test evidence
☐ Request certifications
☐ Request SOC reports
☐ Request remediation evidence
☐ Perform recurring audits

Review

☐ Frequency understood
☐ Notice period understood
☐ Scope understood
☐ Confidentiality protections considered
☐ Cost implications considered
☐ Alternative assurance accepted where appropriate

---

33. Security Evidence Sharing

Determine what evidence can be shared.

Possible evidence:

☐ ISO certificate
☐ SOC report
☐ VAPT summary
☐ Security questionnaire
☐ Security policy summary
☐ Business continuity evidence
☐ DR test summary
☐ Security assessment
☐ Penetration-test remediation summary

Avoid sharing:

• Passwords
• API keys
• Private keys
• Authentication secrets
• Sensitive production credentials
• Unnecessary personal information
• Unnecessary security architecture details

---

34. Personnel Security

Review customer requirements relating to employees and contractors.

☐ Background verification
☐ Confidentiality agreements
☐ Security awareness
☐ Security training
☐ Role-based training
☐ Personnel location
☐ Privileged personnel restrictions
☐ Personnel termination
☐ Customer approval

Verify that requirements are legally and operationally achievable.

---

35. Physical Security

Where relevant:

☐ Office security
☐ Data center security
☐ Visitor controls
☐ Physical access controls
☐ CCTV
☐ Equipment protection
☐ Secure disposal
☐ Environmental controls

For cloud services, distinguish between controls operated by the organization and controls operated by the cloud provider.

---

36. Cloud Security

For SaaS/cloud services, review:

☐ Cloud provider
☐ Cloud regions
☐ Shared responsibility
☐ IAM
☐ MFA
☐ Network security
☐ Encryption
☐ Logging
☐ Monitoring
☐ Backup
☐ Vulnerability management
☐ Configuration management
☐ Secrets management
☐ Security testing
☐ Cloud incident response

AWS Example

For an AWS SaaS service, consider:

• IAM
• Organizations
• CloudTrail
• CloudWatch
• GuardDuty
• Security Hub
• KMS
• Secrets Manager
• VPC
• Security Groups
• WAF
• S3
• RDS
• ECS/EKS
• Backup
• CI/CD

Only commit to controls actually implemented and within the organization’s responsibility.

---

37. Supplier and Third-Party Requirements

Review whether customer contracts impose obligations concerning:

☐ Cloud providers
☐ SaaS providers
☐ Subprocessors
☐ Consultants
☐ Managed service providers
☐ Security providers
☐ Hosting providers
☐ Support providers

Determine whether customer approval is required before changing critical suppliers.

---

38. AI and Generative AI Requirements

If AI is used to provide the service, review:

☐ AI use disclosed where required
☐ Customer data use defined
☐ Customer data used for model training?
☐ Data retention defined
☐ AI provider identified
☐ AI subprocessors identified
☐ Security controls defined
☐ Human review requirements
☐ Confidential information restrictions
☐ Personal-data restrictions
☐ Customer approval requirements

Do not make representations about AI data usage that have not been technically verified.

---

39. Regulatory Requirements

Determine whether the customer contract incorporates regulatory obligations.

☐ Privacy requirements
☐ Financial-sector requirements
☐ Healthcare requirements
☐ Payment requirements
☐ Government requirements
☐ Data residency requirements
☐ Sector-specific requirements

Map applicable requirements to the Legal & Regulatory Requirements Register.

---

40. Insurance Requirements

Review whether the customer contract requires:

☐ Cyber insurance
☐ Professional liability insurance
☐ General liability insurance
☐ Minimum coverage
☐ Evidence/certificate
☐ Notification of policy changes

Confirm with the appropriate business/legal owner before committing.

---

41. Security Liability and Indemnity

Security-related legal terms should be reviewed by authorized legal personnel.

Identify:

☐ Security-related indemnity
☐ Data breach liability
☐ Cyber incident liability
☐ Service credits
☐ Contractual penalties
☐ Liability caps
☐ Exceptions to liability caps
☐ Regulatory fines
☐ Third-party claims
☐ Insurance requirements

The security reviewer should identify the security implications, while legal counsel should determine the legal interpretation and acceptability.

---

42. Right to Change Security Controls

Review whether the contract:

• Requires specific technologies
• Requires specific security controls
• Allows equivalent controls
• Requires customer approval before changes
• Restricts security architecture changes

Where possible, avoid unnecessary commitments to a specific technology when an equivalent control may satisfy the security objective.

---

43. Security Exceptions

Identify any customer requirements the organization cannot currently meet.

Requirement	Gap	Risk	Proposed Exception	Approval	Expiry
Annual on-site audit	Capability unavailable	Medium	Remote audit/assurance report	Legal/Customer

Exceptions should be:

• Explicit
• Documented
• Approved
• Risk assessed
• Time-bound where appropriate
• Reviewed

Do not silently ignore contractual requirements.

---

44. Contractual Requirement Feasibility Assessment

Before accepting significant requirements, ask:

People

☐ Do we have the required skills?
☐ Is staffing sufficient?

Technology

☐ Can our systems support the requirement?
☐ Can the control be monitored?

Process

☐ Do we have the required procedure?
☐ Can the process operate consistently?

Evidence

☐ Can we produce evidence?
☐ Can we meet reporting requirements?

Timing

☐ Can we meet deadlines?

Cost

☐ Are additional security resources required?

Risk

☐ Is the commitment consistent with our risk appetite?

---

45. Security Requirement Acceptance

Before contract approval, classify the requirement.

☐ Already Implemented
☐ Implementable Before Go-Live
☐ Implementable During Contract
☐ Requires Customer Exception
☐ Requires Additional Investment
☐ Requires Risk Acceptance
☐ Cannot Be Met

Requirements that cannot be met should be resolved before contractual commitment wherever practical.

---

46. Contractual Security Requirement Register Update

After completing the review:

☐ Requirements extracted
☐ Requirement IDs assigned
☐ Owners assigned
☐ Controls mapped
☐ Evidence identified
☐ Gaps recorded
☐ Risks recorded
☐ Corrective actions created
☐ Exceptions documented
☐ Review dates assigned
☐ Contractual Security Requirements Register updated

---

47. Approval

Security Review

Reviewer: __________________________

Role: ______________________________

Date: ______________________________

☐ Security requirements acceptable
☐ Conditions identified
☐ Remediation required
☐ Exception required

Legal Review

Reviewer: __________________________

Date: ______________________________

☐ Reviewed
☐ Comments recorded

Business Approval

Owner: _____________________________

Date: ______________________________

☐ Approved
☐ Approved with Conditions
☐ Further Review Required

---

48. Final Contract Review Summary

Area	Result	Finding/Action
Confidentiality
Information Security
Privacy
Access Control
Encryption
Vulnerability Management
Security Testing
Incident Management
Business Continuity
Disaster Recovery
Data Retention
Data Deletion
Subprocessors
Cloud Security
Audit Rights
Certifications
Customer Reporting
Liability/Insurance
AI
Overall Security Risk

---

49. Contract Approval Decision

Result

☐ Approved
☐ Approved with Conditions
☐ Approved Subject to Remediation
☐ Customer Exception Required
☐ Risk Acceptance Required
☐ Further Review Required
☐ Not Approved

Conditions

Required Actions

Approval Authority

Name: ______________________________

Role: _______________________________

Date: _______________________________

---

50. Post-Signing Activities

Once the contract is executed:

☐ Contract stored in approved repository
☐ Security requirements entered into register
☐ Owners notified
☐ Controls implemented
☐ Required access configured
☐ Customer contacts recorded
☐ Incident contacts recorded
☐ Reporting calendar established
☐ Testing calendar established
☐ Certification requirements tracked
☐ BCP/DR commitments tracked
☐ Data-processing requirements tracked
☐ Review date established

---

51. Contract Renewal Review

Before renewal:

☐ Security requirements reviewed
☐ New clauses identified
☐ Customer requirements changed?
☐ Security incidents reviewed
☐ Open gaps reviewed
☐ SLA performance reviewed
☐ VAPT completed
☐ SOC/ISO evidence current
☐ DR testing completed
☐ Subprocessors reviewed
☐ Data locations reviewed
☐ Data retention reviewed
☐ Contractual exceptions reviewed
☐ New risks assessed
☐ Register updated

---

52. Contract Change Review

When the contract changes:

Change Identified

→ Security Impact Assessed

→ Requirements Compared

→ New Obligations Identified

→ Risk Assessed

→ Controls Reviewed

→ Evidence Reviewed

→ Gaps Identified

→ Owners Assigned

→ Contract Approved

→ Register Updated

---

53. AWS SaaS Startup Example

A SaaS startup receives a customer MSA containing the following requirements:

• SOC 2 Type II
• MFA
• Encryption
• Annual VAPT
• Incident notification
• 4-hour RTO
• 1-hour RPO
• Customer-data deletion after termination
• Subprocessor notification

The security review should not simply mark these requirements as “Accepted.”

The organization should determine:

Requirement	Assessment
SOC 2 Type II	Confirm current scope/report
MFA	Verify implementation
Encryption	Verify AWS configuration
Annual VAPT	Confirm testing schedule
Incident notification	Verify escalation process
4-hour RTO	Compare with BIA/DR capability
1-hour RPO	Validate backup/replication capability
Data deletion	Validate deletion procedure
Subprocessors	Review Subprocessor Register

If the organization cannot currently demonstrate a 4-hour RTO or 1-hour RPO, that issue should be addressed before accepting the contractual commitment, rather than discovered after a service disruption.

---

54. Common Mistakes

Avoid:

• Signing contracts without security review.
• Reviewing only the security addendum.
• Ignoring requirements in the SLA or SOW.
• Accepting customer questionnaires without validating answers.
• Making commitments based on planned controls that do not yet exist.
• Promising unrealistic RTO/RPO values.
• Agreeing to notification periods the incident process cannot meet.
• Ignoring data-location requirements.
• Ignoring subprocessor requirements.
• Ignoring deletion requirements.
• Assuming ISO 27001 certification satisfies every customer requirement.
• Assuming SOC 2 satisfies every contractual requirement.
• Accepting technology-specific commitments unnecessarily.
• Failing to document exceptions.
• Failing to update the security register after signing.
• Failing to review requirements during renewal.

---

55. Relationship With Other ISMS Documents

Document	Relationship
Legal & Regulatory Requirements Register	Identifies legal/regulatory obligations
Contractual Security Requirements Register	Records contractual obligations
Requirement-to-Control Mapping Matrix	Maps requirements to controls
Customer Security Questionnaire	Captures customer security questions/commitments
Risk Register	Records contractual risks
Access Control Policy	Implements access requirements
Incident Response Procedure	Implements incident commitments
Data Breach Procedure	Supports breach obligations
Backup & Restore Procedure	Supports backup commitments
BIA	Establishes business impact and recovery requirements
RTO/RPO Assessment	Validates recovery commitments
DR Plan	Implements recovery capability
DR Test Plan	Tests recovery commitments
Supplier/Subprocessor Register	Tracks third-party requirements
Corrective Action Tracker	Tracks contractual gaps
ISMS Improvement Log	Tracks improvements
Management Review	Reviews significant contractual security issues

---

56. Audit Evidence

The organization should retain appropriate evidence demonstrating that customer security commitments were reviewed and managed.

Evidence may include:

• Completed contract security review
• Contract version reviewed
• Security addendum
• DPA
• Customer security questionnaire
• Requirement-to-control mapping
• Contractual Security Requirements Register
• Risk assessment
• Security exceptions
• Risk acceptance
• Approval records
• Security testing evidence
• SOC/ISO reports
• Access review evidence
• Incident records
• BCP/DR test results
• Data deletion evidence
• Subprocessor records
• Corrective action records
• Contract renewal review

---

57. Final Audit Trail

For a significant customer contract, the organization should be able to demonstrate:

Contract Received

→ Scope Understood

→ Security Clauses Identified

→ Data Requirements Identified

→ Legal/Privacy Requirements Identified

→ Security Requirements Extracted

→ Requirements Assessed

→ Risk Assessed

→ Controls Mapped

→ Implementation Feasibility Confirmed

→ Gaps Identified

→ Exceptions/Risk Acceptance Addressed

→ Security Approval Obtained

→ Contract Executed

→ Requirements Added to Register

→ Controls Implemented

→ Evidence Collected

→ Requirements Monitored

→ Contract Renewed/Changed

→ Security Review Repeated

---

58. Final Principle

A customer contract is not just a legal document. It can become a set of operational security commitments.

The organization should therefore review the contract before making commitments and determine:

What did the customer require?

What information is involved?

What security controls are required?

Can we actually meet the requirement?

Who owns it?

What evidence will prove compliance?

What happens if we cannot meet it?

When must it be reviewed again?

Practical Principle

Read → Identify → Assess → Validate → Map → Approve → Commit → Implement → Evidence → Monitor → Review

For a startup, this process prevents an important problem:

Sales promises → Contract commitments → Security obligations → Operational reality

The goal of the checklist is to ensure those four things remain aligned before the organization signs the contract.