Supplier Register

1. Purpose

The Supplier Register is a centralized record of suppliers and third-party service providers that support the organization’s business, technology, information-security, or operational activities.

It helps the organization understand:

• Who its suppliers are
• What services they provide
• Which business processes depend on them
• What information and assets they access
• Whether they have production or privileged access
• What security and privacy risks they introduce
• What contractual and security requirements apply
• When suppliers must be reviewed or reassessed
• What happens when the supplier relationship ends

Core Principle

Know the Supplier → Understand the Service → Identify Information/Access → Assess Risk → Apply Controls → Monitor → Review → Exit

---

2. Scope

The Supplier Register may include:

• Cloud service providers
• SaaS providers
• IT service providers
• Managed service providers
• Software vendors
• Hosting providers
• Data processors
• Consultants
• Contractors
• VAPT providers
• Security service providers
• Audit and certification providers
• Payment service providers
• HR/payroll providers
• Backup providers
• Network providers
• Development partners
• BPO providers
• Infrastructure suppliers
• Customer-support platforms
• Critical business service providers

The organization should determine which suppliers require inclusion based on its risk-management methodology.

---

3. Supplier Register – Master Fields

Field	Description
Supplier ID	Unique supplier identifier
Supplier Name	Legal/business name
Supplier Type	Cloud, SaaS, IT, consultant, etc.
Service/Product	Service provided
Business Process	Process supported
Business Owner	Internal business owner
Supplier Owner	Person managing supplier relationship
Supplier Contact	Primary supplier contact
Security Contact	Supplier security contact
Service Description	Description of service
Business Criticality	Critical / High / Medium / Low
Information Accessed	Information handled
Information Classification	Public / Internal / Confidential / Restricted
Customer Data	Yes / No
Personal Data	Yes / No
Financial Data	Yes / No
Security Information	Yes / No
Production Access	Yes / No
Privileged Access	Yes / No
Cloud Access	Yes / No
Source-Code Access	Yes / No
Database Access	Yes / No
Contract	Reference/status
NDA	Reference/status
DPA	Reference/status
Security Agreement	Reference/status
Security Assessment	Completed / Pending
Risk Assessment	Completed / Pending
Security Assurance	ISO/SOC/etc.
Subprocessors	Yes / No
Data Location	Country/region
Incident Requirements	Defined / Not Defined
Review Frequency	Risk-based frequency
Last Review	Date
Next Review	Date
Risk Level	Low / Medium / High / Critical
Status	Proposed / Active / Suspended / Terminated
Exit Date	If applicable
Evidence Reference	Location of evidence
Remarks	Additional information

---

4. Sample Supplier Register

ID	Supplier	Type	Service	Criticality	Data	Risk	Status
SUP-001	AWS	Cloud	Production hosting	Critical	Customer Data	High	Active
SUP-002	GitHub	SaaS	Source-code repository	High	Source Code	High	Active
SUP-003	VAPT Provider	Security	Security testing	High	Security Information	Medium	Active
SUP-004	HR Platform	SaaS	HR management	High	Employee Data	High	Active
SUP-005	Payment Provider	Payment	Payment processing	Critical	Financial Data	High	Active
SUP-006	Office Cleaning Vendor	Facilities	Office services	Low	Limited/Internal	Low	Active

These entries are examples only. Actual supplier classification and risk should be based on the organization’s environment and approved risk methodology.

---

5. Supplier Identification

Every supplier should have a unique identifier.

Example:

SUP-001

The identifier should remain stable throughout the supplier relationship where practical.

Recommended Naming

SUP-001, SUP-002, SUP-003…

Avoid using supplier names as the only identifier because suppliers may change legal or trading names.

---

6. Supplier Type

Classify the supplier according to the service provided.

Examples:

• Cloud Provider
• SaaS Provider
• Software Vendor
• IT Service Provider
• Managed Service Provider
• Security Provider
• Consultant
• Contractor
• Auditor
• Certification Body
• Payment Provider
• HR Provider
• Payroll Provider
• BPO Provider
• Hosting Provider
• Telecom Provider
• Backup Provider
• Infrastructure Provider
• Development Partner

---

7. Service and Business Process

Record what the supplier actually provides.

Example

Supplier: AWS

Service: Cloud infrastructure

Business Process: SaaS application hosting

Business Dependency: Production application and customer database

This allows the organization to understand the business impact if the supplier becomes unavailable or compromised.

---

8. Supplier Ownership

Each important supplier should have an internal owner.

Business Owner

Responsible for the business relationship and business need.

Supplier Owner

Responsible for managing the supplier relationship and coordinating reviews.

System/Technical Owner

Responsible for technical integration, configuration, or access.

Security/ISMS

Provides security-risk oversight where appropriate.

Procurement

Manages commercial and contractual processes.

Legal/Privacy

Reviews legal, privacy, contractual, and regulatory requirements where applicable.

One person may perform multiple roles in a small organization, provided responsibilities and appropriate review/approval are maintained.

---

9. Supplier Criticality

A practical classification may be:

Critical

Failure or compromise could significantly affect:

• Critical business operations
• Customer services
• Production systems
• Sensitive information
• Regulatory obligations

High

Supplier failure or compromise could materially affect business operations or information security.

Medium

Supplier supports important but non-critical activities.

Low

Supplier has limited business, information, or security impact.

These categories are examples. The organization should define its own criteria.

---

10. Information Access

Record what information the supplier can access.

Examples:

• Customer information
• Employee information
• Personal data
• Financial information
• Source code
• Security reports
• Vulnerability information
• Contracts
• Business plans
• Audit evidence
• Credentials or secrets
• Public information

---

11. Information Classification

Record the highest relevant classification.

Example:

Supplier	Information	Classification
AWS	Customer database	Confidential
GitHub	Source code	Confidential
VAPT Provider	Vulnerability report	Restricted
Public Hosting Provider	Public website	Public

Classification should follow the organization’s Information Classification Policy.

---

12. Supplier Access

Record whether the supplier has access to organizational systems.

Access	Yes/No
Corporate Systems
SaaS
Cloud
Production
Development
Database
Source Code
Customer Systems
VPN
Privileged Access
Physical Facilities

Supplier access should be linked to the applicable access-control records.

---

13. Privileged Supplier Access

Identify suppliers with elevated permissions.

Examples:

• Cloud administrator
• Database administrator
• Security platform administrator
• Network administrator
• Production support
• Infrastructure management
• Identity-management administrator

For privileged supplier access, record:

• Individual identity
• Business justification
• Approver
• System
• Role
• Start date
• Expiry date where applicable
• MFA
• Logging
• Review date
• Revocation status

---

14. Contract Information

Record the contractual relationship.

Field	Details
Contract Number
Contract Start
Contract End
Renewal Date
SOW
NDA
DPA
Security Schedule
SLA
Contract Owner

---

15. Supplier Security Requirements

Record whether security requirements have been incorporated into the supplier relationship.

Consider:

• Confidentiality
• Access control
• Authentication
• Information protection
• Encryption
• Incident notification
• Vulnerability management
• Security testing
• Business continuity
• Data retention
• Data deletion
• Subprocessors
• Data location
• Security assurance
• Audit/assessment rights where appropriate
• Termination requirements

---

16. Supplier Security Assessment

Record the status of the supplier’s security assessment.

Field	Status
Security Questionnaire	Completed / Pending
Security Assessment	Completed / Pending
Risk Assessment	Completed / Pending
Assurance Evidence	Reviewed / Pending
Contract Security Review	Completed / Pending
Privacy Review	Completed / Pending / N/A

---

17. Security Assurance

Record relevant supplier assurance.

Examples:

• ISO/IEC 27001 certification
• SOC 2 report
• Penetration-testing report
• Security assessment
• Vulnerability assessment
• Business-continuity evidence
• Independent audit
• Industry certification

Important

A certification or assurance report should not automatically be treated as proof that every organizational requirement is satisfied.

Consider:

• Scope
• Validity period
• Service covered
• Locations
• Exceptions
• Relevant control coverage

---

18. Supplier Risk

Record the result of the organization’s supplier risk assessment.

Example

Supplier	Initial Risk	Treatment	Residual Risk
AWS	High	Access controls, monitoring, continuity	Medium
GitHub	High	MFA, SSO, repository controls	Medium
VAPT Provider	Medium	NDA, restricted access, expiry	Low

The risk assessment should be maintained separately where detailed analysis is required.

---

19. Subprocessors and Subcontractors

Record whether the supplier uses other organizations to deliver its service.

Supplier	Subprocessor	Service	Data/Access	Location	Reviewed

Consider:

• What service they provide
• What information they access
• Where they operate
• Security requirements
• Contractual flow-down
• Incident notification
• Data deletion
• Change notification

---

20. Data Location

Record where supplier-controlled information is:

• Stored
• Processed
• Backed up
• Transferred

Example:

Primary Region: India
Backup Region: Singapore
Processing: India/United States

Where personal or regulated information is involved, applicable data-transfer and privacy requirements should also be assessed.

---

21. Supplier Incident Requirements

Record whether supplier incident requirements are defined.

☐ Security incident notification
☐ Data breach notification
☐ Vulnerability notification
☐ Service outage notification
☐ Investigation cooperation
☐ Evidence preservation
☐ Customer communication
☐ Regulatory cooperation

Supplier Incident Contact

Name: ______________________

Email: ______________________

Phone: ______________________

---

22. Supplier Business Continuity

Record whether the supplier supports business continuity requirements.

Consider:

• Backup
• Disaster recovery
• Service resilience
• Recovery objectives
• Recovery testing
• Availability
• Alternative arrangements
• Exit/migration capability

Assessment

---

23. Supplier Review Frequency

Review frequency should be based on supplier risk and business importance.

For example:

Supplier Risk	Example Review Approach
Critical	Enhanced/frequent review
High	Periodic detailed review
Medium	Periodic review
Low	Risk-based/basic review

These frequencies are examples, not universal ISO 27001 requirements.

---

24. Supplier Review Record

For each review, record:

Field	Details
Supplier ID
Review Date
Reviewer
Risk Level
Security Assessment
Security Assurance
Incidents
Vulnerabilities
Access Review
Contract Review
Subprocessor Changes
Data Location Changes
Business Continuity
Findings
Corrective Actions
Risk Reassessment
Next Review

---

25. Supplier Risk Reassessment Triggers

Update the supplier risk assessment when relevant changes occur.

Examples:

• New service
• New customer information
• New personal data
• New production access
• New privileged access
• New subprocessor
• New geographic location
• Major security incident
• Major vulnerability
• Supplier acquisition
• Supplier ownership change
• Major technology change
• Contract change
• Regulatory change
• Change in business criticality

Process

Change → Impact Assessment → Risk Reassessment → Control Update → Approval → Register Update

---

26. Supplier Security Findings

Track significant supplier-security findings.

Finding ID	Supplier	Finding	Risk	Action	Owner	Due Date	Status

Findings may originate from:

• Questionnaire
• Security assessment
• Audit
• Incident
• Vulnerability assessment
• Contract review
• Access review
• Business continuity review

---

27. Corrective Action Tracking

Action ID	Supplier	Corrective Action	Owner	Due Date	Evidence	Status

Closure should be supported by appropriate evidence.

---

28. Supplier Status

Recommended statuses:

Proposed

Supplier is being evaluated.

Under Assessment

Security/risk assessment is in progress.

Approved

Required reviews and approvals are complete.

Active

Supplier is currently providing services.

Suspended

Supplier relationship is temporarily restricted.

Terminating

Supplier relationship is being closed.

Terminated

Supplier relationship has ended and exit activities are complete.

---

29. Supplier Offboarding

When a supplier relationship ends, verify:

☐ Supplier access revoked
☐ Privileged access revoked
☐ Cloud access removed
☐ SaaS access removed
☐ VPN access removed
☐ Customer-system access removed
☐ API credentials/tokens addressed
☐ Organizational information returned/deleted where required
☐ Subprocessor access addressed
☐ Physical assets returned
☐ Secrets rotated where necessary
☐ Contract closed
☐ Exit evidence retained
☐ Supplier Register updated

Exit Principle

Revoke → Return/Delete → Verify → Record → Close

---

30. AWS SaaS Startup Example

A startup may maintain the following entries:

ID	Supplier	Service	Access	Information	Risk
SUP-001	AWS	Cloud hosting	Production infrastructure	Customer Data	High
SUP-002	GitHub	Source control	Source code	Confidential	High
SUP-003	VAPT Provider	Security testing	Temporary testing access	Restricted Security Info	Medium
SUP-004	HR SaaS	HR management	Employee data	Confidential	High
SUP-005	Payment Provider	Payments	API integration	Financial Data	High

For AWS, the register should not simply say “Cloud Provider.”

It should identify the actual dependency:

AWS → Production SaaS → Customer Database → Customer Information → Critical Business Service

This makes the supplier relationship useful for risk assessment and audit purposes.

---

31. Supplier Register vs Supplier Risk Assessment

These documents serve different purposes.

Supplier Register	Supplier Risk Assessment
Who is the supplier?	What risks does the supplier introduce?
What service do they provide?	What could go wrong?
What information do they access?	How likely is it?
What systems do they access?	What would be the impact?
Who owns the relationship?	What controls exist?
When is it reviewed?	What treatment is required?
Current status	What residual risk remains?

The Supplier Register provides the central inventory.

The Supplier Risk Assessment provides the risk analysis.

---

32. Supplier Register vs Supplier Security Questionnaire

Register	Questionnaire
Internal organizational record	Information collected from supplier
Maintained by organization	Completed by supplier
Identifies supplier	Assesses supplier controls
Tracks risk/status	Provides security evidence
Supports ongoing monitoring	Supports due diligence

A questionnaire response can therefore become an input to the Supplier Risk Assessment and Supplier Register.

---

33. Recommended Supplier Management Structure

A practical supplier-management structure is:

1. Supplier Register

Who are our suppliers?

↓

2. Supplier Security Questionnaire

What security controls does the supplier have?

↓

3. Supplier Risk Assessment

What risk does this supplier introduce?

↓

4. Supplier Security Agreement

What security requirements must the supplier meet?

↓

5. Supplier Review

Are the controls still operating and appropriate?

↓

6. Supplier Offboarding

Has access and information been securely handled when the relationship ends?

---

34. Startup-Friendly Minimum Supplier Register

A startup can begin with these minimum fields:

Supplier	Service	Business Owner	Information	Classification	Access	Criticality	Risk	Contract	Last Review	Next Review	Status

As the ISMS matures, additional fields can be added.

The objective is not to create a large spreadsheet. The objective is to maintain an accurate and useful view of supplier relationships and their security implications.

---

35. Audit Evidence

An auditor may sample suppliers and trace:

Supplier Register

→ Contract

→ Security Questionnaire

→ Supplier Security Assessment

→ Risk Assessment

→ Security Requirements

→ Access Records

→ Security Assurance

→ Periodic Review

→ Findings

→ Corrective Actions

→ Risk Reassessment

The organization should be able to demonstrate that supplier risks are actively managed rather than merely listed.

---

36. Common Supplier Register Mistakes

Avoid:

• Maintaining only supplier names and contact details.
• Treating the register as a procurement spreadsheet.
• Not identifying business owners.
• Not identifying information accessed.
• Not recording supplier system access.
• Not identifying production or privileged access.
• Not recording supplier criticality.
• Not linking suppliers to risk assessments.
• Not tracking security-assessment status.
• Not tracking subcontractors/subprocessors.
• Not tracking data locations.
• Not tracking security incidents.
• Not reviewing suppliers periodically.
• Not updating the register after major changes.
• Keeping terminated suppliers as “Active.”
• Failing to verify supplier exit activities.

---

37. ISO 27001 Connection

The Supplier Register supports the organization’s risk-based management of supplier relationships and related areas such as:

• Supplier relationships
• Supplier agreements
• ICT supply-chain security
• Monitoring of supplier services
• Access control
• Information transfer
• Incident management
• Business continuity
• Information classification
• Risk management

The Supplier Register itself is not a universally mandatory ISO 27001 document. The organization should determine the information and records it needs to maintain based on its ISMS, risks, contractual obligations, legal/regulatory requirements, and supplier relationships.

The applicable Annex A controls should be determined through the organization’s risk assessment and Statement of Applicability.

---

38. Quick Audit Checklist

Supplier Identification

☐ Supplier identified
☐ Unique Supplier ID assigned
☐ Service documented
☐ Business owner assigned
☐ Supplier owner assigned

Information

☐ Information accessed identified
☐ Classification identified
☐ Customer data considered
☐ Personal data considered
☐ Sensitive information considered

Access

☐ System access identified
☐ Production access identified
☐ Privileged access identified
☐ Cloud access identified
☐ Source-code access identified

Risk

☐ Criticality assessed
☐ Supplier risk assessed
☐ Risk treatment identified
☐ Residual risk considered

Security

☐ Security assessment status recorded
☐ Security assurance recorded
☐ Incident requirements recorded
☐ Business continuity considered
☐ Subprocessors identified

Contract

☐ Contract recorded
☐ NDA recorded
☐ DPA considered
☐ Security requirements recorded
☐ Termination requirements defined

Monitoring

☐ Review frequency defined
☐ Last review recorded
☐ Next review recorded
☐ Findings tracked
☐ Corrective actions tracked

Exit

☐ Access revocation process defined
☐ Data return/deletion addressed
☐ Supplier status updated after termination

---

39. Final Audit Trail

For every significant supplier, the organization should be able to answer:

Who is the supplier?
What service does it provide?
What business process depends on it?
What information does it access?
What systems does it access?
Does it have production or privileged access?
What risk does it introduce?
What security requirements apply?
What assurance do we have?
Who owns the relationship?
When was it last reviewed?
When must it be reviewed again?
What happens when the relationship ends?

Final Principle

A Supplier Register should be more than a list of vendors. It should provide a clear view of the organization’s supplier dependencies, information exposure, access, criticality, security risk, ownership, review status, and exit requirements.