1.3 Gather Compliance and Contractual Requirements
Goals
Before a company can properly assess cybersecurity risk, it needs to understand what cybersecurity obligations already apply to the business.
These obligations may come from laws, regulations, customer contracts, vendor agreements, cyber insurance policies, payment processors, industry standards, privacy rules, or promises the company has made in writing.
This step is not the full compliance audit or the full risk assessment. The goal here is to gather the requirements, organize them, and make sure the company knows what it is already expected to do.
Many companies assume cybersecurity requirements only come from government regulations but some of the strongest cybersecurity obligations may already be hidden inside customer contracts, vendor agreements, SaaS terms, insurance questionnaires, data processing agreements, or security addendums.
If the company does not collect these requirements, it cannot know whether it is meeting them.
Why This Matters
Cybersecurity is not only about what the company wants to protect. It is also about what the company has promised to protect.
A company may have agreed to notify customers within a certain time after a security incident. It may have promised to use MFA. It may have agreed to encrypt sensitive data. It may have accepted audit rights from a customer. It may have told a cyber insurer that backups are tested or that endpoint protection is deployed. It may be required to protect payment card data, health data, financial data, personal data, confidential business data, or government-related information.
If these obligations are scattered across contracts, inboxes, PDF files, insurance forms, and old procurement folders, the company is exposed.
This section helps bring those obligations into one place.
What the Company Should Gather
The company should collect all documents that may contain cybersecurity, privacy, data handling, incident response, or technology requirements.
This should include:
- Customer contracts
- Master service agreements
- Statements of work
- Data processing agreements
- Privacy addendums
- Security addendums
- Vendor agreements
- Supplier contracts
- SaaS agreements
- Managed service provider agreements
- Payment processor agreements
- Cyber insurance applications and policy documents
- Client security questionnaires
- Audit reports or customer security reviews
- Regulatory guidance relevant to the business
- Industry standards the company claims to follow
- Internal security policies already shared with customers
- Privacy policies published on company websites
- Terms of service published to customers
If the document says anything about data, systems, access, security, privacy, confidentiality, breach notification, backups, audit rights, or service availability, collect it.
Practical Tasks for the Company
Task 1: Assign an Owner for Requirements Collection
The company should assign one person or role to coordinate this work.
This does not mean that one person knows every requirement. It means one person is responsible for making sure the requirements are collected and organized.
Good candidates include the Operations manager, IT manager, Security lead, Compliance lead, Legal or contract manager, Office manager in a smaller SME or similar.
The owner should coordinate with leadership, finance, legal, sales, HR, IT, procurement, and any MSP or outsourced technology provider.
The output should be a named owner and a clear deadline for the initial collection.
Task 2: Create a Central Requirements Folder
Do not let this work live in scattered email threads.
Create one central folder for all collected documents. This can be in SharePoint, Google Drive, OneDrive, Nextcloud, or another approved company document system.
Suggested folder structure:
- Compliance and Contractual Requirements
- Customer Contracts
- Vendor Contracts
- Insurance Documents
- Regulatory Requirements
- Security Questionnaires
- Data Processing Agreements
- Internal Policies
- Evidence and Supporting Documents
- Open Questions
The folder should have controlled access. Sensitive contracts and insurance documents should not be available to everyone. It might be advisable to only include the portion of the documents that pertains to security and data preservation obligations
The output should be one organized document repository.
Task 3: Identify Which Laws and Regulations May Apply
The company should make a first-pass list of laws or regulations that may apply based on where it operates, who its customers are, what data it handles, and what industry it serves.
This is not a legal opinion and final interpretation should come from qualified counsel where needed. The purpose here is to identify likely obligations that should be reviewed.
Examples of areas to check:
- Personal data and privacy
- Payment card data
- Health information
- Financial customer information
- Government contract information
- Children’s data
- Employee data
- Consumer data
- International data transfers
- Sector-specific cybersecurity rules
- Data breach notification requirements
Common examples include:
- GDPR / EDPB SME Data Protection Guide
- UK ICO Small Organization Data Protection Assessment
- California Consumer Privacy Act
- FTC Cybersecurity for Small Business
- FTC Safeguards Rule
- HIPAA
- PCI DSS
- CMMC
- NIS2 Directive
- NYDFS Cybersecurity Regulation
The output should be a short “possible regulatory obligations” list.
Task 4: Collect Customer Security Requirements
Many customer contracts contain cybersecurity obligations. These may be in the main contract, a security schedule, a data processing agreement, a confidentiality clause, or a procurement questionnaire.
Look for clauses that mention:
- Information security program
- Access control
- MFA
- Encryption
- Data handling
- Data retention
- Data deletion
- Breach notification
- Incident response
- Audit rights
- Vulnerability management
- Penetration testing
- Employee background checks
- Security training
- Subcontractor controls
- Data location
- Business continuity
- Disaster recovery
- Cyber insurance
- Compliance with specific frameworks
- Customer approval before using subcontractors
The company should not trust memory here. The actual contract language matters.
The output should be a collected set of customer cybersecurity obligations.
Task 5: Collect Vendor and Third-Party Security Obligations
The company should also collect requirements from vendors, SaaS platforms, IT providers, MSPs, cloud providers, payment processors, payroll providers, website developers, accountants, marketing platforms, and other third parties.
This work looks in two directions.
-
First, what does the vendor require from the company?
-
Second, what does the company require from the vendor?
For example, a SaaS provider may require the company to manage user access securely. A payment processor may require PCI DSS compliance. A customer may require the company to ensure that its subcontractors meet similar security standards.
The output should be a vendor and third-party obligations list.
Task 6: Collect Cyber Insurance Requirements
If the company has cyber insurance, collect the full policy, application, renewal questionnaire, exclusions, endorsements, incident reporting instructions, and broker communications.
Pay special attention to statements the company made during the application or renewal process.
Common insurance-related areas include: MFA, Endpoint protection, Backups, Backup testing, Patch management, an Incident response plan, Security awareness training and more.
This matters because inaccurate answers on an insurance questionnaire can create serious problems later. If the company told the insurer that a control exists, the company should know whether that control is actually in place.
The output should be a cyber insurance obligations summary.
Task 7: Extract the Actual Requirements
After the documents are collected, the company should extract the actual cybersecurity and privacy requirements into a simple register.
Do not only save the PDF. Pull the obligation out into a usable format.
Suggested columns:
- Requirement ID
- Source document
- Customer, vendor, law, regulation, or insurer
- Exact clause or requirement summary
- Affected system, data, department, or process
- Requirement type
- Required action
- Deadline or review frequency
- Internal owner
- Evidence needed
- Current status
- Open questions
- Notes
Example:
- Requirement ID: CR-001
- Source: Customer MSA, Section 8.4
- Requirement: Notify customer of confirmed security incident affecting customer data within 72 hours.
- Affected area: Customer data, incident response, legal notification
- Owner: Operations Manager and IT Lead
- Evidence needed: Incident response procedure, customer notification process, incident log template
- Status: Needs review
This is where the work becomes useful.
The output should be a compliance and contractual requirements register.
Task 8: Separate Hard Requirements from General Expectations
Not every clause carries the same weight. The company should separate requirements into practical categories:
- Required: The company must do this because of law, regulation, contract, insurance, or signed commitment.
- Expected: The customer, industry, or insurer expects this, even if the exact language is less strict.
- Recommended: A strong practice that is useful but not yet required.
- Unknown: Needs legal, customer, insurer, or leadership clarification.
This prevents confusion. A legal requirement is not the same as a best practice. A customer contract obligation is not the same as a blog recommendation. A cyber insurance promise is not optional if the company relies on the policy.
The output should be a requirement priority label for each item.
Task 9: Identify Evidence the Company May Need
Many companies say they have security controls, but cannot prove them.
For each major requirement, the company should identify what evidence would be needed if a customer, auditor, insurer, regulator, or executive asked for proof.
Evidence may include:
- Written policy
- System screenshot
- Access review record
- MFA report
- Backup test result
- Training completion record
- Vendor review record
- Incident response plan
- Patch report
- Vulnerability scan report
- Penetration test report
- Encryption configuration
- Data deletion confirmation
- Security questionnaire response
- Cyber insurance application
- Signed agreement
- Audit report
The goal is not to collect all evidence yet. That can be handled later. The goal in this section is to know what evidence may be required.
The output should be an evidence-needed column in the requirements register.
Task 10: Identify Conflicts and Unclear Obligations
Contracts are not always clean. One customer may require 24-hour incident notification. Another may require 72 hours. A vendor may limit liability while the company has promised stronger guarantees to its own customer. A cyber insurance policy may require using an approved incident response provider before certain work begins.
These conflicts should be flagged early.
Examples of items to flag:
- Different incident notification timelines
- Different encryption expectations
- Different data retention periods
- Different audit rights
- Conflicting subcontractor obligations
- Different backup or recovery requirements
- Unclear definitions of “security incident”
- Unclear definition of “personal data” or “customer data”
- Promises made in sales security questionnaires that are not backed by internal controls
The output should be a list of unclear or conflicting obligations.
Task 11: Create a Review Schedule
Requirements change. Contracts renew. Insurance questionnaires update. New vendors are added. New customers ask for security commitments. Regulations evolve.
The company should review this requirements register on a fixed schedule.
Recommended review timing:
- At least annually
- Before cyber insurance renewal
- Before signing major customer contracts
- Before onboarding high-risk vendors
- After major business changes
- After entering a new market or region
- After launching a new product or service
- After a major security incident
The output should be a review cadence and calendar owner.
Tools to Help With This Work
Your company does not need expensive tooling to begin, a clean spreadsheet and disciplined folder structure can work well for many SMEs.
However, tools can help once the requirements list becomes larger.
Online Resources to Use
Suggested Requirements Register Template
The company should create a simple tracker with these fields:
- Requirement ID
- Requirement source
- Source type
- Customer, vendor, regulator, insurer, or internal policy
- Requirement summary
- Exact contract clause or reference
- Affected system or data
- Affected department
- Required action
- Required deadline
- Evidence needed
- Internal owner
- Status
- Open questions
- Review date
- Notes
Suggested source types:
- Law or regulation
- Customer contract
- Vendor contract
- Cyber insurance
- Payment processor
- Security questionnaire
- Internal policy
- Industry standard
- Framework
- SaaS agreement
Expected Outputs from This Section
At the end of this section, the company should have:
- A named owner for gathering compliance and contractual requirements.
- A central folder containing relevant contracts, policies, insurance documents, regulatory notes, and security questionnaires.
- A list of possible laws and regulations that may apply.
- A list of customer cybersecurity requirements.
- A list of vendor and third-party obligations.
- A cyber insurance obligations summary.
- A compliance and contractual requirements register.
- A list of evidence the company may need to produce.
- A list of unclear or conflicting obligations.
- A review schedule for keeping the register current.
Objective
The company should leave this section able to say:
“We know which cybersecurity, privacy, contract, customer, vendor, and insurance requirements apply or may apply to us. We know where those requirements are written. We know who owns them. We know what evidence may be needed. And we know which unclear items need follow-up.”
That is the right foundation before moving into the risk assessment.