1. Purpose
The ICT Dependency Register is a centralized record of the technology and related dependencies required to deliver critical business services.
It helps the organization understand:
- What each critical business service depends on.
- Which ICT systems support the service.
- Which information and data are required.
- Which cloud and SaaS services are involved.
- Which suppliers are critical.
- Which people or roles are required.
- What happens if a dependency becomes unavailable.
- How the dependency will be recovered or replaced.
The register supports business continuity, disaster recovery, risk management, incident management, supplier management, and ICT resilience.
2. Scope
The register should cover dependencies associated with:
- Business applications
- Production systems
- Databases
- Cloud infrastructure
- SaaS applications
- Networks
- Internet connectivity
- DNS
- Identity and SSO
- MFA
- Security services
- Backup systems
- Monitoring and logging
- Source code repositories
- CI/CD platforms
- APIs
- Third-party integrations
- Technology suppliers
- Critical personnel
- Facilities and utilities where relevant
- Recovery environments
3. Dependency Principle
A business service rarely depends on a single application.
A typical dependency chain may look like:
Customer Service
↓
SaaS Application
↓
Application Infrastructure
↓
Database
↓
Cloud Provider
↓
Identity
↓
Network
↓
Security Services
↓
Third-Party APIs
↓
People / Suppliers
The purpose of the register is to make these relationships visible.
4. Dependency Categories
| Category | Examples |
|---|---|
| Application | SaaS application, ERP, CRM |
| Infrastructure | VM, container, server, storage |
| Cloud | AWS, Azure, GCP |
| Database | RDS, PostgreSQL, MySQL |
| Network | Internet, VPN, firewall, DNS |
| Identity | SSO, IAM, MFA |
| Security | WAF, EDR, SIEM, security monitoring |
| Data | Customer data, financial data, logs |
| Backup | Backup platform, storage, replication |
| Development | GitHub, GitLab, CI/CD |
| SaaS | Microsoft 365, Google Workspace, Slack |
| API | Payment, messaging, identity APIs |
| Supplier | Cloud provider, MSP, SaaS vendor |
| People | Administrator, system owner, specialist |
| Facility | Office, data center, power, connectivity |
| Recovery | DR environment, recovery account |
5. Register Information
| Field | Details |
|---|---|
| Register Name | ICT Dependency Register |
| Register Owner | |
| Business Owner | |
| ICT Owner | |
| Version | |
| Effective Date | |
| Review Frequency | |
| Last Review | |
| Next Review |
6. Master ICT Dependency Register
| Dependency ID | Business Service | ICT Service | Dependency | Category | Criticality | Owner | Supplier | RTO | RPO | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| DEP-001 | Customer SaaS | Production | AWS | Cloud | Critical | AWS | 4h | 1h | Active | |
| DEP-002 | Customer SaaS | Database | Amazon RDS | Database | Critical | AWS | 4h | 1h | Active | |
| DEP-003 | Customer SaaS | Identity | IdP/SSO | Identity | High | 4h | 4h | Active | ||
| DEP-004 | Customer SaaS | DNS | DNS Provider | Network | High | 4h | N/A | Active | ||
| DEP-005 | Product Delivery | CI/CD | CI/CD Platform | Development | High | 8h | 4h | Active | ||
| DEP-006 | Business Operations | Collaboration | SaaS Platform | SaaS | Medium | 8h | 24h | Active |
The RTO/RPO values above are examples only and should be established through the organization’s Business Impact Assessment and RTO/RPO assessment.
7. Dependency Identification
For each critical business service, ask:
Business
- What business service is being delivered?
- Which business process depends on it?
- Who owns the business service?
- How critical is it?
Technology
- Which applications are required?
- Which infrastructure is required?
- Which databases are required?
- Which cloud services are required?
Information
- What information is required?
- Where is the information stored?
- How frequently does it change?
- What happens if it becomes unavailable?
Access
- Which identities are required?
- Is SSO required?
- Is MFA required?
- Which privileged roles are needed?
Network
- Is Internet connectivity required?
- Is VPN required?
- Is DNS required?
- Are firewall/WAF services required?
Suppliers
- Which third parties are required?
- What happens if the supplier becomes unavailable?
- Are alternative suppliers available?
People
- Which roles are required?
- Is specialist knowledge required?
- Is there a single point of failure?
8. Detailed Dependency Record
Each important dependency should have a detailed record.
Dependency Identification
| Field | Details |
|---|---|
| Dependency ID | DEP-YYYY-XXXX |
| Business Service | |
| Business Process | |
| ICT Service | |
| Dependency Name | |
| Dependency Type | |
| Description | |
| Business Owner | |
| Technical Owner | |
| Supplier | |
| Status | Active / Planned / Retired |
9. Business Criticality
| Field | Assessment |
|---|---|
| Business Criticality | Critical / High / Medium / Low |
| Customer Impact | |
| Revenue Impact | |
| Operational Impact | |
| Security Impact | |
| Regulatory Impact | |
| Contractual Impact | |
| Maximum Tolerable Disruption | |
| Required RTO | |
| Required RPO |
10. Dependency Relationship
Document exactly what the dependency provides.
| Dependency | Provides | Required By | Failure Impact |
|---|---|---|---|
| AWS | Cloud infrastructure | Production SaaS | Service unavailable |
| RDS | Customer database | Application | Customer data unavailable |
| IdP | Authentication | Workforce/Application | Users/admins cannot authenticate |
| DNS | Domain resolution | Customer application | Customers cannot reach service |
| Payment API | Payment processing | Billing | Transactions affected |
11. Upstream and Downstream Dependencies
Dependencies should be viewed in both directions.
Upstream Dependency
Something that the service depends upon.
Example:
SaaS Application → RDS
The application depends on the database.
Downstream Dependency
A service that depends on the current service.
Example:
Billing System → SaaS API
Billing depends on the SaaS API.
Record both where relevant.
12. Dependency Mapping
For critical services, create a simple dependency map.
Example:
Customer SaaS
→ DNS
→ CDN/WAF
→ Load Balancer
→ Application
→ Database
→ Storage
→ Identity
→ Secrets
→ Encryption Keys
→ Monitoring
→ CI/CD
→ Third-Party APIs
→ Cloud Provider
This provides a practical view of the service’s technology ecosystem.
13. Data Dependency
Record information dependencies separately where appropriate.
| Information | System | Location | Criticality | RPO | Backup | Owner |
|---|---|---|---|---|---|---|
| Customer Data | RDS | AWS | Critical | 1h | PITR | |
| Customer Documents | S3 | AWS | High | 4h | Versioning | |
| Audit Logs | Cloud Logging | AWS | High | 24h | Protected Storage | |
| Source Code | Git Platform | SaaS | High | 4h | Repository Backup |
14. Identity and Access Dependencies
A service may be technically available but unusable if its identity dependency fails.
Record:
- Identity provider
- SSO
- MFA
- IAM
- Privileged roles
- Service accounts
- API credentials
- Secrets
- Recovery accounts
- Break-glass accounts
Example:
Production AWS → IAM → Identity Provider → MFA
If the identity provider is unavailable, administrators may be unable to perform recovery activities.
This makes identity a potential recovery dependency.
15. Network Dependencies
Record critical network dependencies such as:
- Internet connectivity
- ISP
- VPN
- Firewall
- WAF
- DNS
- Load balancer
- CDN
- Private connectivity
- Routing
- Network security services
Example:
Customer → DNS → CDN/WAF → Load Balancer → Application
Failure at any critical point may affect service availability.
16. Cloud Dependency Assessment
For cloud services, record:
| Field | Assessment |
|---|---|
| Cloud Provider | |
| Account/Tenant | |
| Region | |
| Availability Zones | |
| Critical Services | |
| Storage | |
| Database | |
| Compute | |
| Network | |
| Identity | |
| Security Services | |
| Backup | |
| Monitoring | |
| Recovery Environment | |
| Provider Support |
The organization should understand its responsibilities under the applicable cloud provider’s shared-responsibility model.
17. AWS SaaS Example
Consider a SaaS startup operating on AWS.
Business Service
Customer SaaS Platform
Dependency chain
Customer
↓
Route 53
↓
CloudFront/WAF
↓
Load Balancer
↓
ECS
↓
RDS
↓
S3
Supporting dependencies:
- IAM
- KMS
- Secrets Manager
- CloudWatch
- CloudTrail
- GuardDuty
- Security Hub
- CI/CD
- Git repository
- Third-party APIs
The organization should not record only “AWS” as the dependency.
The register should identify the services inside AWS that are actually required to operate and recover the customer service.
18. Supplier Dependency
For each supplier, record:
| Field | Details |
|---|---|
| Supplier | |
| Service | |
| Business Service Supported | |
| Criticality | |
| Data Processed | |
| Access Provided | |
| Contract | |
| SLA | |
| RTO | |
| RPO | |
| Supplier BCP | |
| Supplier DR Capability | |
| Security Assurance | |
| Subprocessors | |
| Incident Contact | |
| Emergency Contact | |
| Exit Strategy | |
| Alternative Available |
Critical suppliers should link to the organization’s supplier risk and monitoring processes.
19. People Dependency
Technology continuity may depend on individuals with specialized knowledge.
Record:
| Role | Service | Criticality | Single Person Dependency? | Backup Resource |
|---|---|---|---|---|
| AWS Administrator | Production | Critical | Yes/No | |
| Database Administrator | RDS | High | Yes/No | |
| DevOps Lead | CI/CD | High | Yes/No | |
| Security Lead | Security Monitoring | High | Yes/No |
Where practical, organizations should reduce single-person dependency through:
- Documentation
- Cross-training
- Knowledge transfer
- Secondary administrators
- Recovery runbooks
- Secure emergency access
20. Single Points of Failure
Identify dependencies where one failure can cause major disruption.
| Dependency | Single Point of Failure? | Impact | Mitigation |
|---|---|---|---|
| Single DNS provider | Yes | Customer access affected | Secondary strategy |
| Single administrator | Yes | Recovery delayed | Cross-training |
| Single database | Yes | Customer service affected | Backup/replication |
| Single API provider | Yes | Feature unavailable | Alternative/manual process |
A single point of failure is not automatically unacceptable. The organization should determine whether the risk is acceptable based on business requirements.
21. Dependency Failure Assessment
For each critical dependency:
| Question | Assessment |
|---|---|
| What happens if it becomes unavailable? | |
| How quickly does impact begin? | |
| Which services are affected? | |
| Which customers are affected? | |
| Is there an alternative? | |
| Can the dependency be bypassed? | |
| Is a manual workaround available? | |
| How quickly can it be restored? | |
| Does the supplier have a recovery plan? | |
| Does our RTO depend on this supplier? | |
| Does our RPO depend on this supplier? |
22. Dependency Risk Assessment
A dependency should be assessed based on:
Criticality × Failure Likelihood × Business Impact × Recovery Difficulty
Consider:
- Confidentiality impact
- Integrity impact
- Availability impact
- Customer impact
- Financial impact
- Regulatory impact
- Contractual impact
- Security impact
- Recovery dependency
- Supplier dependency
23. Dependency Risk Register
| Risk ID | Dependency | Threat | Vulnerability | Impact | Likelihood | Risk | Treatment | Owner |
|---|---|---|---|---|---|---|---|---|
| R-001 | DNS Provider | Provider outage | Single provider | Customer access unavailable | Medium | High | Resilience strategy | |
| R-002 | AWS Region | Region outage | Single-region architecture | Production unavailable | Low/Med | High | DR strategy | |
| R-003 | AWS Admin | Person unavailable | Single administrator | Recovery delayed | Medium | High | Cross-training | |
| R-004 | Payment API | Supplier outage | No alternative | Billing affected | Medium | Medium | Contingency process |
Risk ratings should follow the organization’s approved risk methodology.
24. Dependency Resilience Strategy
For important dependencies, document the treatment.
Possible strategies:
Avoid
Remove unnecessary dependency.
Reduce
Reduce dependency through architecture or process changes.
Transfer
Use contractual or supplier arrangements where appropriate.
Accept
Accept the residual dependency risk through authorized risk acceptance.
Resilience
Introduce redundancy, replication, alternative suppliers, or manual workarounds.
25. Recovery Dependency
A critical dependency should also be assessed from a recovery perspective.
Example:
The organization wants to restore its application within 4 hours.
But recovery requires:
- Cloud account access
- Identity provider
- MFA
- DNS
- Infrastructure-as-code repository
- Database backup
- Secrets
- Encryption keys
- DevOps administrator
Therefore:
Application RTO = 4 hours
is meaningful only if the dependencies required to achieve that recovery are also available within the recovery process.
26. Dependency Testing
Critical dependencies should be considered during continuity and DR testing.
Examples:
- Cloud outage test
- DNS failure test
- Database restoration
- Identity provider outage
- Backup restoration
- Supplier outage
- API failure
- Network failure
- Emergency administrator access
- CI/CD recovery
Record:
| Dependency | Test | Expected Result | Actual Result | Gap |
|---|---|---|---|---|
| RDS | Database restore | Within RTO | ||
| DNS | DNS recovery | Service reachable | ||
| IdP | Emergency access | Admin recovery possible | ||
| Backup | Restore test | Data recoverable |
27. Dependency Monitoring
Critical dependencies should be monitored according to their risk.
Monitoring may include:
- Availability
- Performance
- Security alerts
- Supplier incidents
- Service status
- Contract/SLA performance
- Certificate expiration
- API availability
- Backup status
- Capacity
- Configuration changes
For critical suppliers, monitoring may also include periodic security and continuity reviews.
28. Dependency Change Management
The register should be updated when:
- A new critical system is introduced.
- A supplier changes.
- Cloud architecture changes.
- An application changes.
- A database changes.
- A critical API changes.
- A recovery strategy changes.
- A service is retired.
- A dependency becomes more critical.
- A new single point of failure is introduced.
Dependency changes should be evaluated for their effect on:
- Risk
- RTO/RPO
- BCP
- DR
- Security
- Supplier management
- Incident response
29. Dependency Review
Review each critical dependency periodically.
Review Questions
- Is the dependency still required?
- Is the criticality still correct?
- Has the architecture changed?
- Has the supplier changed?
- Has the dependency’s security posture changed?
- Has the RTO/RPO changed?
- Is there a new single point of failure?
- Is the recovery method still valid?
- Has the dependency been tested?
- Are contact details current?
- Is an alternative available?
- Are corrective actions outstanding?
30. Dependency Status
Use consistent status values:
- Planned
- Active
- Under Review
- At Risk
- Temporarily Unavailable
- Retiring
- Retired
31. Dependency Register Minimum Fields
A startup can begin with the following fields:
| Field |
|---|
| Dependency ID |
| Business Service |
| ICT Service |
| Dependency |
| Category |
| Criticality |
| Owner |
| Supplier |
| Data Involved |
| Access Required |
| RTO |
| RPO |
| Failure Impact |
| Recovery Method |
| Alternative |
| Single Point of Failure |
| Last Test |
| Risk |
| Status |
| Review Date |
This is usually sufficient to establish a practical baseline before introducing more detailed dependency mapping.
32. Startup Implementation
For a startup, begin with the top critical customer and business services.
For each service, document:
1. What does the service do?
Example:
Customer SaaS Platform
2. What does it depend on?
AWS + RDS + S3 + IAM + DNS + CI/CD + APIs
3. What information does it require?
Customer Data + Application Configuration + Logs
4. Who provides it?
AWS + SaaS Suppliers + Internal Team
5. What happens if it fails?
Customer service unavailable
6. How quickly must it recover?
RTO = 4 hours
7. How much data loss is acceptable?
RPO = 1 hour
8. Has the dependency been tested?
Yes/No
This creates a useful dependency map without creating unnecessary bureaucracy.
33. Relationship With Other ISMS Records
The ICT Dependency Register should connect with:
Business Impact Assessment
↓
Critical Service Register
↓
ICT Dependency Register
↓
Risk Assessment
↓
RTO/RPO Assessment
↓
ICT Business Continuity Plan
↓
Disaster Recovery Plan
↓
Supplier Risk Management
↓
Recovery Testing
↓
Corrective Action Tracker
↓
ISMS Improvement Log
This relationship makes dependency management part of the ISMS rather than a standalone spreadsheet.
34. Audit Evidence
An auditor should be able to select a critical business service and trace:
Business Service
→ ICT Service
→ Application
→ Infrastructure
→ Data
→ Identity
→ Network
→ Supplier
→ Dependency Risk
→ RTO/RPO
→ Recovery Strategy
→ Test Result
→ Corrective Action
Example:
Customer SaaS
→ ECS
→ RDS
→ S3
→ IAM
→ DNS
→ AWS
→ Third-party payment API
→ Critical dependencies identified
→ RTO 4h / RPO 1h
→ DR strategy
→ Recovery test
→ Results recorded
→ Improvement action
35. Final Audit Trail
Business Service Identified
→ ICT Service Identified
→ Dependencies Identified
→ Dependency Category Assigned
→ Criticality Assessed
→ Business Impact Assessed
→ Supplier/Data/Access Dependencies Identified
→ Single Points of Failure Identified
→ RTO/RPO Requirements Linked
→ Dependency Risk Assessed
→ Resilience Strategy Defined
→ Recovery Capability Established
→ Dependency Tested
→ Results Recorded
→ Gaps Identified
→ Corrective Actions Assigned
→ Dependency Register Updated
→ Risk Reassessed
36. Final Principle
You cannot recover a critical business service unless you understand what that service depends on.
Map the Business Service + Identify the Technology + Identify the Data + Identify Access + Identify Suppliers + Identify People + Identify Single Points of Failure + Assess Dependency Risk + Link RTO/RPO + Test Recovery + Keep the Register Current.