1. Purpose
The Critical Technology Dependency Assessment is used to identify and evaluate technology components, platforms, services, suppliers, and infrastructure on which critical business services depend.
The assessment helps the organization understand:
- Which technologies are critical to business operations
- What would happen if a technology became unavailable, compromised, or unsupported
- Whether the organization has adequate security and resilience controls
- Whether there are single points of failure or excessive dependency
- Whether alternative, backup, recovery, or exit arrangements exist
- Whether the dependency creates information-security, operational, regulatory, or supplier risk
The objective is not simply to create an inventory of technology. It is to understand the business impact of depending on that technology.
2. Core Assessment Principle
A useful assessment follows this chain:
Business Service → Application → Technology → Supplier → Information → Dependency → Failure Scenario → Impact → Risk → Controls → Recovery/Alternative → Residual Risk
For example:
Customer-facing SaaS platform → Production application → AWS → EC2/RDS/S3/IAM → Customer data → High dependency → AWS service outage → Customer service unavailable → High business risk → Multi-AZ deployment + backups + monitoring → Recovery/alternative arrangements → Residual risk accepted
3. When Should the Assessment Be Performed?
Perform the assessment when:
- A new critical technology is introduced
- A new production application is implemented
- A critical supplier is selected
- A technology becomes business-critical
- A major architecture change occurs
- A critical cloud service is introduced
- A technology reaches end-of-life
- A major vulnerability affects the technology
- A supplier changes its service significantly
- Recovery arrangements change
- A single point of failure is identified
- A critical incident occurs
- Business processes become dependent on a new technology
- Periodic technology-risk reviews are performed
4. Technology Dependency Assessment Record
| Field | Details |
|---|---|
| Assessment ID | TDA-001 |
| Technology/Dependency | |
| Technology Type | Cloud / SaaS / Database / Network / Identity / Application / Other |
| Business Service | |
| Application/System | |
| Technology Owner | |
| Business Owner | |
| Supplier/Provider | |
| Supplier ID | |
| Criticality | Low / Medium / High / Critical |
| Assessment Date | |
| Assessment Trigger | New / Review / Change / Incident / Other |
| Next Review Date | |
| Status | Open / Approved / Remediation / Accepted / Closed |
5. Business Service Dependency
Identify the business service that depends on the technology.
| Field | Assessment |
|---|---|
| Business Service | |
| Business Process | |
| Customer-Facing? | Yes / No |
| Revenue Impact | Yes / No |
| Regulatory Impact | Yes / No |
| Security Impact | Yes / No |
| Operational Impact | |
| Business Owner | |
| Maximum Acceptable Downtime | |
| Recovery Requirement |
Example
A SaaS company may identify:
Business Service: Customer SaaS Platform
Business Process: Customer application delivery
Dependency: AWS production infrastructure
Impact: Customers cannot access the platform if critical infrastructure becomes unavailable.
6. Technology Identification
Document the technology on which the service depends.
| Field | Details |
|---|---|
| Technology Name | |
| Technology Type | |
| Product/Service | |
| Version | |
| Environment | Production / Development / Test |
| Architecture Component | |
| Hosting Model | Cloud / On-Premises / Hybrid |
| Supplier | |
| Region/Location | |
| Owner | |
| Administrator | |
| Related Application | |
| Related Asset ID |
Examples include:
- AWS
- Microsoft Azure
- Google Cloud
- PostgreSQL
- Kubernetes
- Identity provider
- DNS provider
- CDN
- Payment gateway
- Backup platform
- Git repository
- CI/CD platform
- Security monitoring platform
7. Dependency Type
Classify the dependency.
| Dependency | Applicable? |
|---|---|
| Cloud Infrastructure | Yes / No |
| SaaS Platform | Yes / No |
| Database | Yes / No |
| Identity & Authentication | Yes / No |
| Network | Yes / No |
| DNS | Yes / No |
| CDN | Yes / No |
| Source Code Repository | Yes / No |
| CI/CD | Yes / No |
| Backup | Yes / No |
| Security Monitoring | Yes / No |
| Payment Processing | Yes / No |
| API/External Service | Yes / No |
| Hardware | Yes / No |
| Software Component | Yes / No |
| Managed Service | Yes / No |
| Other |
8. Information Dependency
Identify the information processed, stored, transmitted, or made available through the technology.
| Field | Details |
|---|---|
| Information Type | |
| Classification | Public / Internal / Confidential / Restricted |
| Customer Data | Yes / No |
| Personal Data | Yes / No |
| Financial Data | Yes / No |
| Authentication Data | Yes / No |
| Source Code | Yes / No |
| Security Information | Yes / No |
| Regulatory Data | Yes / No |
| Data Volume | |
| Data Location | |
| Retention Requirement |
The assessment should consider whether compromise or unavailability of the technology could affect:
Confidentiality → Integrity → Availability
9. Access Dependency
Determine how the organization depends on the technology for access.
| Question | Response |
|---|---|
| Does production depend on it? | |
| Does administrative access depend on it? | |
| Does employee authentication depend on it? | |
| Does customer authentication depend on it? | |
| Is privileged access involved? | |
| Is remote access involved? | |
| Are service accounts involved? | |
| Are API keys/tokens involved? | |
| Is MFA available? | |
| Is break-glass access available? |
Special attention should be given to technologies that control access to other critical systems.
For example:
If the organization’s identity provider becomes unavailable, administrators may be unable to access AWS, production systems, or security platforms.
10. Dependency Criticality Assessment
Assess how critical the dependency is to the organization.
Suggested classification
| Level | Description |
|---|---|
| Low | Failure has limited business or security impact. |
| Medium | Failure causes noticeable operational disruption but alternatives may exist. |
| High | Failure significantly affects important business services, customers, security, or compliance. |
| Critical | Failure can materially interrupt critical services, cause significant data/security impact, or prevent recovery of important operations. |
These classifications should be adapted to the organization’s own risk methodology.
11. Dependency Factors
Evaluate the following factors:
11.1 Business Criticality
- Does the technology support a critical business process?
- Does revenue depend on it?
- Does customer service depend on it?
- Does a regulatory obligation depend on it?
11.2 Availability Dependency
- Can the organization operate without it?
- For how long?
- Is there redundancy?
- Is there a backup service?
11.3 Security Dependency
- Could compromise affect other systems?
- Does the technology hold privileged credentials?
- Does it control authentication?
- Does it have access to sensitive information?
11.4 Supplier Dependency
- Is there only one supplier?
- Is the supplier difficult to replace?
- Is migration technically difficult?
- Are there contractual restrictions?
11.5 Recovery Dependency
- Can the technology be restored?
- Are backups available?
- Has recovery been tested?
- Is the recovery process dependent on another unavailable system?
12. Failure Scenario Assessment
Assess realistic failure scenarios.
| Scenario | Likelihood | Impact | Risk |
|---|---|---|---|
| Service outage | |||
| Supplier failure | |||
| Cyberattack | |||
| Data corruption | |||
| Unauthorized access | |||
| Technology failure | |||
| Configuration error | |||
| Loss of credentials | |||
| Supplier account compromise | |||
| End-of-life technology | |||
| Loss of connectivity | |||
| Region/provider outage |
13. Single Point of Failure Assessment
Determine whether the technology represents a single point of failure (SPOF).
Ask:
- Is there only one technology provider?
- Is there only one instance?
- Is there only one administrator?
- Is there only one authentication mechanism?
- Is there only one network path?
- Is there only one backup mechanism?
- Is there only one region?
- Is there only one person who understands the technology?
- Is recovery dependent on the same failed system?
Assessment
SPOF Identified: Yes / No
Description:
Business Impact:
Mitigation Required:
14. Supplier Dependency
Where the technology is provided by an external supplier, assess:
- Supplier criticality
- Supplier financial/operational dependency
- Security assurance
- Certifications or independent assurance
- Incident notification
- Business continuity
- Disaster recovery
- Subprocessors
- Data location
- Contractual protections
- Exit provisions
- Data portability
- Migration capability
- Service availability
- Supplier concentration risk
Relevant supplier records should be cross-referenced rather than duplicated.
15. Concentration Risk
Assess whether too many important services depend on the same technology or supplier.
Example:
If the organization uses one cloud provider for production hosting, backup, monitoring, logging, and disaster recovery, a major provider-level disruption could affect several recovery mechanisms simultaneously.
Record:
| Field | Details |
|---|---|
| Supplier/Technology | |
| Number of Critical Services Dependent | |
| Number of Applications | |
| Number of Recovery Functions | |
| Alternative Provider | |
| Migration Difficulty | |
| Concentration Risk | Low / Medium / High |
| Treatment Required |
16. Recovery Assessment
Determine how the organization would recover if the technology became unavailable.
| Recovery Question | Response |
|---|---|
| Backup available? | |
| Backup independent from primary system? | |
| Recovery procedure documented? | |
| Recovery tested? | |
| RTO defined? | |
| RPO defined? | |
| Alternative technology available? | |
| Alternative supplier available? | |
| Data export possible? | |
| Migration procedure available? | |
| Recovery owner identified? |
17. Exit and Migration Assessment
For critical technologies, determine whether the organization can reasonably exit the dependency.
Consider:
- Data export capability
- Data portability
- API availability
- Contract termination requirements
- Migration tooling
- Alternative suppliers
- Migration cost
- Migration time
- Technical compatibility
- Staff capability
- Data deletion requirements
- Dependency on proprietary technology
Exit Assessment
Can the organization migrate? Yes / No / Partially
Estimated migration period:
Alternative technology:
Key migration constraints:
Exit plan required: Yes / No
18. Security Control Assessment
Evaluate existing controls.
| Control Area | Status | Evidence |
|---|---|---|
| MFA | ||
| Least Privilege | ||
| Privileged Access Management | ||
| Encryption | ||
| Backup | ||
| Logging | ||
| Monitoring | ||
| Vulnerability Management | ||
| Patch Management | ||
| Network Security | ||
| Secure Configuration | ||
| Incident Response | ||
| Business Continuity | ||
| Disaster Recovery | ||
| Supplier Security | ||
| Access Review |
19. Risk Assessment
Record the principal risks associated with the dependency.
| Risk ID | Dependency | Threat/Failure | Vulnerability | Impact | Likelihood | Risk |
|---|---|---|---|---|---|---|
| R-001 |
The organization’s approved risk methodology should be used for likelihood, impact, and risk calculation.
20. Risk Treatment
For identified risks, determine the appropriate treatment:
- Mitigate
- Avoid
- Transfer
- Accept
Record:
| Field | Details |
|---|---|
| Risk ID | |
| Treatment | |
| Control/Action | |
| Owner | |
| Target Date | |
| Status | |
| Evidence | |
| Residual Risk | |
| Risk Acceptance Required | Yes / No |
21. Assessment of Residual Risk
After controls and treatment actions are considered:
Inherent Risk:
Existing Controls:
Additional Treatment:
Residual Risk:
Risk Owner:
Risk Acceptance:
Approval Date:
The residual risk should be handled according to the organization’s established risk acceptance process.
22. AWS SaaS Example
Consider a startup operating a customer-facing SaaS platform on AWS.
Dependency
Business Service: Customer SaaS Platform
Technology: AWS
Components:
- EC2/ECS
- RDS
- S3
- IAM
- CloudTrail
- CloudWatch
- KMS
- WAF
- Backup services
Dependency Assessment
| Area | Assessment |
|---|---|
| Business Criticality | Critical |
| Customer Impact | High |
| Customer Data | Yes |
| Production Dependency | Yes |
| Privileged Access | Yes |
| Availability Dependency | High |
| Supplier Dependency | High |
| Single Provider | Yes |
| Backup | Configured |
| Monitoring | Configured |
| MFA | Required |
| Encryption | Enabled |
| Recovery Testing | Periodic |
| Exit Strategy | Documented/Planned |
Example Failure
Scenario: Critical cloud infrastructure becomes unavailable.
Potential impact:
- Customers cannot access the SaaS platform
- Business operations are disrupted
- SLA commitments may be affected
- Revenue may be impacted
- Security monitoring or recovery capability may also be affected
Treatment
Possible controls may include:
- Multi-AZ architecture
- Automated backups
- Tested recovery procedures
- Infrastructure-as-Code
- Centralized logging
- Monitoring and alerting
- Privileged-access controls
- Documented recovery procedures
- Data export capability
- Technology exit/migration planning
The exact controls should be determined through the organization’s risk assessment rather than automatically applying every possible control.
23. Startup-Friendly Assessment Model
A startup does not need to perform a complex assessment for every technology.
Tier 1 — Standard Dependency
Examples:
- Low-impact SaaS
- Non-critical development tools
- General productivity applications
Basic assessment may be sufficient.
Tier 2 — Important Dependency
Examples:
- HR systems
- CRM
- Security tools
- Development platforms
- Internal databases
Perform a more detailed security and continuity assessment.
Tier 3 — Critical Dependency
Examples:
- Production cloud platform
- Identity provider
- Customer database
- Payment infrastructure
- Core SaaS platform
- Critical backup platform
Perform enhanced assessment covering:
Security + Availability + Recovery + Supplier + Concentration + Exit/Migration + Residual Risk
24. Relationship With Other ISMS Documents
The Critical Technology Dependency Assessment should connect with other ISMS records.
| Document | Relationship |
|---|---|
| Asset Register | Identifies the technology asset |
| ICT Dependency Register | Records the technology dependency |
| Supplier Register | Identifies the technology supplier |
| Critical Supplier Register | Identifies critical external providers |
| Supplier Risk Assessment | Evaluates supplier-related risk |
| Risk Register | Records significant risks |
| Business Continuity Plan | Defines continuity/recovery arrangements |
| Disaster Recovery Plan | Defines technical recovery |
| Software Dependency Inventory | Tracks software components |
| SBOM | Provides component-level software visibility |
| Access Review | Verifies access to critical technology |
| Vulnerability Register | Tracks technology vulnerabilities |
| Incident Register | Records technology-related incidents |
| Statement of Applicability | Connects applicable security controls |
25. Roles and Responsibilities
Business Owner
- Identifies business dependency
- Defines business impact
- Confirms criticality
- Participates in risk decisions
Technology/System Owner
- Provides technical information
- Identifies architecture and dependencies
- Maintains technical controls
- Supports recovery planning
Information Security
- Reviews security risks
- Evaluates security controls
- Supports risk assessment
- Tracks security treatment
Procurement/Supplier Management
- Reviews supplier dependency
- Maintains supplier information
- Supports contractual requirements
Risk Owner
- Owns identified risk
- Approves or escalates treatment
- Accepts residual risk where authorized
26. Evidence to Retain
Typical evidence may include:
- Completed assessment
- Architecture diagrams
- Dependency maps
- Asset records
- Supplier records
- Contracts
- Security assessments
- Risk assessments
- Backup evidence
- Recovery-test results
- Access reviews
- Vulnerability reports
- Monitoring evidence
- Incident records
- Exit/migration plans
- Risk treatment records
- Risk acceptance approvals
- Review records
Do not store passwords, API keys, private keys, or other secrets in the assessment.
27. Review Triggers
Reassess the dependency when:
- Technology changes
- Supplier changes
- Architecture changes
- New customer data is introduced
- Classification changes
- Privileged access changes
- Major vulnerability is identified
- Security incident occurs
- Service availability changes
- Contract changes
- Subprocessor changes
- Technology reaches end-of-life
- Business criticality changes
- Recovery testing identifies weaknesses
28. Quick Audit Checklist
| Question | Yes/No/N/A |
|---|---|
| Are critical technology dependencies identified? | |
| Is each dependency linked to a business service? | |
| Is the technology owner identified? | |
| Is the supplier identified where applicable? | |
| Is information processed by the technology identified? | |
| Is criticality documented? | |
| Has availability dependency been assessed? | |
| Has security dependency been assessed? | |
| Has single-point-of-failure risk been considered? | |
| Has supplier concentration been considered? | |
| Are recovery arrangements documented? | |
| Has exit/migration capability been considered? | |
| Are security controls documented? | |
| Are risks recorded? | |
| Are treatment actions assigned? | |
| Has residual risk been evaluated? | |
| Is appropriate approval recorded? | |
| Is the assessment periodically reviewed? | |
| Is evidence retained? |
29. Recommended Assessment Record
A practical assessment can be maintained as a structured record containing:
Dependency Identification → Business Service → Technology → Supplier → Information → Access → Criticality → Failure Scenarios → SPOF → Concentration Risk → Security Controls → Recovery → Exit/Migration → Risk → Treatment → Residual Risk → Approval → Review
This creates a clear relationship between the technology dependency and the organization’s broader risk-management process.
30. ISO 27001 Connection
ISO/IEC 27001 requires an organization to determine and manage information-security risks within its ISMS. Technology dependencies can form part of that risk landscape where they affect the confidentiality, integrity, or availability of information or supporting business processes.
The assessment should therefore be connected to:
Organizational Context → Asset/Dependency Understanding → Risk Assessment → Risk Treatment → Applicable Controls → Evidence → Monitoring → Continual Improvement
Not every technology requires a formal standalone assessment. The level of assessment should be proportionate to the technology’s business importance, information handled, access, supplier dependency, security risk, regulatory/contractual requirements, and recovery requirements.
31. Final Audit Trail
A strong audit trail should demonstrate:
Business Service Identified
↓
Technology Dependency Identified
↓
Information & Access Assessed
↓
Criticality Determined
↓
Failure & Dependency Risks Assessed
↓
Security & Recovery Controls Reviewed
↓
Supplier/Concentration/Exit Risk Considered
↓
Risk Recorded
↓
Treatment Implemented
↓
Residual Risk Evaluated
↓
Risk Approved
↓
Dependency Monitored & Periodically Reassessed
Final Principle
A critical technology dependency should never be assessed only by asking “Is the technology secure?”
The more important question is:
“What critical business service depends on this technology, what happens if it fails or is compromised, and can the organization continue, recover, or exit the dependency?”
That approach turns a technology inventory into a meaningful business, security, resilience, and risk-management assessment.