A shared identity platform
A critical application may depend on an identity service used across the enterprise. Include that dependency rather than examining only application servers.

National Cybersecurity Authority
Protect critical services through NCA CSCC readiness, dependency mapping, strengthened access, monitoring and tested recovery.
Critical Systems Cybersecurity Controls complement and extend ECC for national critical systems. NCA's published CSCC document addresses governance, defense, resilience and third-party/cloud cybersecurity. Its purpose is more specific than giving every important server a critical label.
A useful program begins with service consequence. Understand what a loss of availability, integrity or confidentiality would mean, which systems support that service and which dependencies could undermine it. Use this picture to prioritize engineering, evidence and recovery validation.
Identify critical systems using the applicable NCA definition and your organization's context. Validate service boundaries, interconnected applications, administrative infrastructure, hosting and supplier dependencies. Business importance alone does not replace the formal applicability assessment.
Treat CSCC as an overlay to the applicable ECC baseline, not a separate replacement. Show how each relevant requirement is implemented across the complete critical-service chain, including outsourced components and recovery environments.
| Focus area | Implementation examples | Evidence to maintain |
|---|---|---|
| Critical-service scope | Map applications, identities, infrastructure and dependency paths. | Approved critical-system register and current diagrams. |
| Administrative protection | Constrain privileged access and separate sensitive management paths. | Privilege approvals, access reviews and session records. |
| System protection | Validate segmentation, secure configuration and controlled change. | Ruleset reviews, change evidence and exception decisions. |
| Detection and response | Prioritize high-consequence events and test escalation ownership. | Detection scenarios, response exercises and corrective actions. |
| Service recovery | Test restoration with required systems and dependencies together. | Recovery runbooks, test results and unresolved limitations. |
A critical application may depend on an identity service used across the enterprise. Include that dependency rather than examining only application servers.
A backup can exist while recovery still fails because credentials, networks, keys or upstream services are unavailable. Validate the restoration sequence against agreed service needs.
Agree the scope, responsible owners and acceptance criteria before work begins. The approach is tailored to your systems, suppliers, operating constraints and existing evidence.
Review applicability, current controls and evidence. Identify gaps and dependencies, distinguish design from operating effectiveness, and prioritize actions with accountable owners.
Translate approved requirements into architecture, policies, processes and technical changes. Reuse effective controls while keeping national and sector mappings distinct.
Configure agreed safeguards, document procedures and validate representative workflows within authorized access and change windows. Record exceptions and residual risks.
Organize evidence, transfer operating knowledge and define a review cadence. Track corrective actions as systems, services, suppliers and requirements change.
Deliverables, depth, access and timing depend on the statement of work. This is readiness and implementation support; it does not include a promise of regulator acceptance or formal certification.
Do not assume so. Apply the official criteria and authority directions, document the reasoning and have the appropriate owners approve the boundary.
No. It extends and complements the baseline for the relevant systems. Map shared evidence and keep additional requirements visible.
A server-only view can miss identities, management networks, integrations, suppliers and recovery dependencies. Agree a service-based boundary before assessing controls.
Validation must be planned around business risk, authorized access and change windows. Start with evidence and configuration review; intrusive testing requires a separately agreed scope.
A critical-service and dependency map, a control gap register, prioritized actions, an evidence list and a validation plan. Detailed deliverables depend on the agreed scope.
Read the linked authority publications for the binding scope, wording and applicable updates. The implementation examples on this page are practical recommendations, not a reproduction of every regulatory requirement.
General readiness and technology information, not a legal opinion, regulator endorsement or guarantee of compliance. Confirm applicability, current versions and sector directions with the competent authority and qualified advisers.
Bring your services, systems, supplier dependencies and existing findings. We will help turn them into a practical assessment and implementation scope.
Discuss your readiness