GV.OC-04 critical services: requirements and evidence

What GV.OC-04 asks you to define about critical services

When a customer questionnaire, contract or regulator asks which services you must keep running for others and how quickly they must return, GV.OC-04 is the Subcategory that requires you to have an answer. It asks the organization to identify the critical objectives, capabilities and services that customers and other external stakeholders rely on or expect, and to make sure those are understood and communicated. The method NIST points to is a business impact analysis that finds vital assets and operations and estimates the impact of losing them, followed by resilience objectives such as recovery time objectives for normal operations, attack conditions and recovery. The risk addressed is familiar: an outage reaches external stakeholders before internal teams agree on what matters most, so the first decisions about restoration are made without a shared priority list. The same Subcategory is also cited in NIST's small business guidance (SP 1300), so the expectation applies at any size, though the depth of the analysis should scale with the organization.

Three things usually make this hard. First, a service that a customer sees as one product often spans several internal teams, such as application, hosting, identity, payments and support, and no single team owns the whole chain. Second, ownership of the service is often unclear, so nobody can state its objectives with authority. Third, objectives are frequently written for IT, such as server uptime or backup frequency, rather than for the service the customer experiences, such as "claims can be submitted within a given window." Start by listing the external commitments you have made in contracts and service descriptions, then map each one to the internal components it depends on. Ask the business owner for the maximum tolerable disruption and the data loss they can accept, and record who approved those figures and when.

Because NIST does not certify organizations or products against CSF 2.0, proof of GV.OC-04 consists of internal records that an independent assessor can sample: the business impact analysis, the criticality criteria, the approved resilience objectives, the service-to-component maps and evidence that these reached the teams that run recovery and the customers who rely on them. Confirm with your assessor which evidence they expect, and keep dated versions so they can see the objectives existed before an incident. An implementation partner can help prepare these records and the underlying systems, but the organization owns the decisions and the independent auditor or assessor issues any report.

Which services, stakeholders and third parties fall under GV.OC-04

GV.OC-04 is only as useful as its boundary. The decisions below determine which services, stakeholders and platforms the business impact analysis and resilience objectives must cover. The organization should draw the boundary around the services it has promised to others, then test that boundary against the reverse inventory maintained under GV.OC-05.

Customer-facing services and their capabilities

Start with the services customers, partners and public bodies can see or contract for, then trace each one down to the capabilities that deliver it, such as authentication, payment processing, reporting or data exports. A service listed in a customer contract or public service catalog belongs in scope even if internal teams consider it minor. Check whether each service has a named owner and a documented recovery expectation, because GV.OC-04 asks for criticality to be set and communicated, not assumed.

External stakeholders who rely on the service

For each service, record who depends on it: customers, regulators, sector bodies, business partners and public agencies. Each group may expect different outcomes, such as continued access during an incident or timely notice of an outage. Capture these expectations from contracts, service level commitments and regulatory filings, and confirm them with the account and compliance owners. Stakeholders who only receive reports, rather than running transactions through the service, still belong in the record if they would be harmed by its loss.

Third-party platforms in the service chain

Hosting providers, managed platforms, payment networks, identity providers and data processors often sit between the organization's capabilities and the customer. An outage in one of them can break a promised service even when the organization's own systems are healthy. Map each hosted component the service needs, note which provider operates it, and record the contractual recovery commitments that provider has agreed to. Where a provider is self-hosted within the organization's own infrastructure, the boundary should still show who operates each layer.

Business unit and data domain splits

Services often cross business units, so one customer-facing product may depend on systems owned by finance, operations and a regional subsidiary. Decide whether the scope follows the service, the owning unit or the data domain, and document the rule. Splitting by unit alone can leave shared components unassigned, while splitting by data domain can hide who is accountable for availability. Confirm that each shared component appears under exactly one accountable owner, with dependent services listed beside it.

Regulated and contractual obligations on the boundary

Some services carry obligations set by law or contract, such as sector rules, supervisory expectations or customer audit rights. These obligations can make a service critical even if its usage is low. Review the requirements tracked under GV.OC-03 and mark every service that a contract or regulator names, so the business impact analysis reflects those commitments. Ask legal and compliance teams to confirm which obligations apply in each jurisdiction where the service is offered.

Cross-checking with the GV.OC-05 inventory

The GV.OC-05 inventory records what the organization itself depends on, so it shows the reverse direction. Keep the two lists separate, then compare them. A dependency that appears in GV.OC-05 but supports no service in GV.OC-04 may be a gap in the service catalog, and a service with no matching dependencies may be missing its supporting components. Reviewers should confirm that each shared dependency is recorded in both places and assigned to one accountable owner.

How a business impact analysis turns services into recovery targets

The GV.OC-04 chain starts with criticality criteria, not with recovery times. Before anyone sets a target, the organization needs written rules for deciding which objectives, capabilities and services matter enough to be treated as critical, and which external stakeholders depend on them. NIST's Implementation Examples for this Subcategory put that step first, and the rules should be agreed with the service owners, not drafted by the security team alone. Ask who relies on each service (customers, payment partners, regulators, downstream suppliers) and what they would expect if it stopped.

Next, a business impact analysis identifies the vital assets and operations that support those services and estimates the impact of losing them. NIST's Implementation Examples describe this as finding what is vital and what happens if it is lost. The Small Business Quick-Start Guide (SP 1300, February 2024) applies the same idea at smaller scale, asking organizations to assess the impact of losing all or part of their critical assets and operations. The output should name the systems, data flows, facilities and third parties behind each service, so that the recovery work in the Recover Function has a clear list to work from.

Finally, set resilience objectives such as recovery time objectives and recovery point objectives, and set them separately for normal operation, a cyberattack and recovery. The same service can tolerate a short outage during routine maintenance but very little disruption during an attack, when containment may force a shutdown, and a different pace again while rebuilding. Confirm the actual durations with the service owners and with the external stakeholders who depend on each service, and record the agreed values in the business continuity and incident response plans so that the figures can be tested in exercises.

Implementing GV.OC-04 step by step

This sequence turns GV.OC-04 from a statement of intent into a set of approved records: which external services matter, how much their loss would hurt, how fast each must come back, and who is told. Each step closes with a document an assessor can read.

Agree criticality criteria with executives
Leadership, usually the COO or business owners together with the CISO, agrees written criteria that decide what counts as critical. Criteria typically cover customer harm, regulatory exposure, financial loss, safety and the number of stakeholders affected. Output: an approved criticality criteria note with a named owner and approval date. The step is done when every business owner can apply the criteria to a service without asking for interpretation.
Build an inventory of externally relied-on services
Working with business owners, list the objectives, capabilities and services that customers, partners, regulators and other outside parties rely on or expect. Start from customer contracts, service descriptions and published commitments, then trace the internal systems and suppliers behind each one. Output: a register of external-facing services with an owner, the customers or stakeholders who depend on each, and the systems that deliver it. The step closes when the register has been reviewed against the sales and contract team's list of commitments.
Run a business impact analysis per service
For each service in the register, the business owner and the risk function run a business impact analysis that estimates what happens if the service stops, degrades or returns corrupted data. The analysis looks at the operations that depend on it, the period after which harm grows, and the dependencies that would fail with it. Output: one impact analysis record per service, signed by the business owner. The step is complete when each critical service has a record that states its dependencies and its tolerance for disruption.
Record impact of loss and affected stakeholders
Using the analysis results, record the impact of losing each critical service on each affected external stakeholder group, such as customers, counterparties, regulators, or downstream service providers. Note which obligations would be breached, such as contractual service levels or notification duties, and which parties must be told first. Output: a stakeholder impact table linked to each service, reviewed by legal and the client-facing teams. The step closes when every critical service has at least one named stakeholder group and one listed obligation, or a documented reason why none applies.
Set recovery objectives for each condition
For each critical service, set resilience objectives, including recovery time objectives, for three conditions: normal operation, during an attack, and during recovery. Objectives under attack conditions often differ from normal ones because containment may isolate systems. The objectives should be justified by the impact analysis and agreed by the business owner. Output: a resilience objectives register that states the value, the condition it applies to, and the justification. Confirm with your own recovery specialists whether the values are achievable with the current backup and restore design before approval.
Link objectives to systems and third parties
Map each recovery objective to the technical components that must meet it, including hosting, applications, data stores, network paths and third-party services such as cloud providers or payment processors. Check whether each third party's contract, service level and exit terms support the objective. Output: a traceability matrix linking every objective to its systems, backup and restore procedures, and supplier commitments, with gaps flagged for remediation. The step is done when no critical objective depends on a component without a named owner.
Approve and communicate the results
Present the criticality criteria, impact records, objectives and traceability matrix to the accountable executive for approval. Once approved, share the parts relevant to each audience with the teams that run operations, the service desk and client-facing staff, and summarize the external commitments for account managers. Output: signed approval minutes and a distribution record showing which teams received which document. The step closes when the approved set is stored in the controlled document repository and the people who must act on it have acknowledged receipt.
Schedule review tied to change management
Set a review cycle for the register, impact analyses and objectives, and attach triggers to the change management process so that new services, major system changes, new third-party dependencies and contract changes prompt an update. Keep a log of each review and its outcome. Output: a review schedule, a change trigger list and a review log that an assessor can compare against the change records. Confirm the review interval with your own governance policy, since this guide does not set one.

How an assessor tests GV.OC-04 and what they ask to see

This table compares what an assessor does for each part of GV.OC-04, the evidence they request and the gaps they most often record. Read each row as a test step: the evidence column shows what to have ready, and the findings column shows where programs usually fall short.

Test area	Evidence requested	Common findings
Criticality criteria approved by leadership	Written criticality criteria, approval record from executive or risk governance, date of last review, and the minutes or sign-off showing who decided them	Criteria exist only in an IT working document, were never approved by leadership, or have not been reviewed since the organization changed its services
Sampled services traced from inventory to business impact analysis	Service inventory extract, for a sample of services the criteria rank as critical, the completed business impact analysis showing the impact of losing each service and its dependencies	Services in the inventory have no business impact analysis, or the analysis lists infrastructure components without naming the customer-facing service they support
Recovery objectives for normal, attack and recovery conditions	Documented recovery time and recovery point objectives per critical service, with separate values or assumptions for normal operations, a cyber attack and the recovery phase	Objectives exist only for infrastructure such as servers or databases, or cover normal operations only with no attack or recovery assumptions
Objectives linked to the systems that deliver them	Mapping from each service objective to the applications, platforms, backups and third parties that must meet it, and evidence that the mapped components were tested against the objective	No traceable link between objectives and delivering systems, so the objective cannot be checked against actual recovery capability
External stakeholder expectations considered	Records showing which customer, partner or regulator expectations shaped the criticality decisions, such as contract service levels or notification commitments	Impact analyses reflect only internal views, and contractual or regulatory commitments are not reflected in the chosen objectives
Results communicated and reviewed after significant change	Distribution list or meeting records for the analysis, review dates, and change records showing the analysis was updated after a major system, provider or service change	Analyses older than the services they describe, with no review after new platforms, acquisitions or outsourcing changes

Evidence that satisfies GV.OC-04 and how to keep it current

An assessor testing GV.OC-04 looks for a chain of records: criteria that define what is critical, an inventory of the services people rely on, analysis of what losing them costs, and objectives that are checked when things change. Each artifact below feeds the next, so keeping them current is mostly a matter of tying them to the change and review processes you already run.

Approved criticality criteria

A short, approved document that defines what makes an objective, capability or service critical to customers, partners and regulators, such as contractual commitments, safety impact or the number of users affected. Assessors ask who approved it and when it was last reviewed. Keep it current by reviewing it during the annual risk review and whenever a new customer contract adds a service commitment. Confirm with your own auditor which approval record they expect.

Service inventory with named owners

A list of the services, objectives and capabilities that external stakeholders rely on, each with a named business owner and a technical owner. The inventory should reference the asset records maintained under ID.AM so that every critical service points to real systems. Check it against customer-facing contracts and status pages. Ask a change board to flag new services or ownership changes so the inventory is updated when the change is approved, not months later.

Completed business impact analyses

Written analyses that show what happens to each critical service if it is lost in whole or part, covering financial, legal, customer and safety effects. NIST's Implementation Examples for GV.OC-04 describe using a business impact analysis to identify vital assets and operations. Date each analysis, record the assumptions and the people interviewed, and re-open it when a critical service changes materially, such as after a platform migration or a new outsourcing arrangement.

Recovery time objectives by scenario

A register of recovery time objectives and related resilience targets for each critical service, separated by normal operation, attack and recovery conditions, as NIST's Implementation Examples describe. Each entry should name the approving executive and the test that proved the target is achievable. Review the register after incident exercises and after any change to backup, failover or hosting design, and record the change ticket that triggered the update.

Dependency map linking services to systems and third parties

A map that connects each critical service to the applications, infrastructure, data stores and external providers it depends on, showing which links would stop the service if they failed. This is the artifact that makes the GV.OC-05 inverse view and supplier risk work visible to an assessor. Regenerate or re-verify the map when architecture changes are approved, and flag any single point of failure for leadership review in the annual risk discussion.

Review records after major change

Dated minutes, tickets or sign-offs showing that criticality, impact analyses and recovery objectives were checked after significant changes and during the annual risk review. Assessors sample these records to see whether the objectives still match the environment. Build a required checkbox into change requests for services in the inventory, and link each review to the risk register entry it affected. Confirm with your assessor how many review cycles they expect to sample for your audit period.

What meeting GV.OC-04 costs in money and effort

This table compares the main cost components of identifying critical services that others depend on, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for a written quote, since no prices or durations are supplied for this topic. The main takeaway is that open-source tooling can remove license spend, but interview and analysis labor remains the largest and least substitutable cost.

Cost component	One-time or recurring	What drives it	How to keep it down
Executive and service owner time to agree criteria	One-time, then recurring at review	Number of business lines, number of decision makers, and how many criteria sets must be agreed	Prepare a draft criteria set before the meeting and limit sign-off to one or two named approvers
Engineering time to build the dependency map	One-time, then recurring	Number of services, depth of dependencies, and whether asset inventories already exist	Start from existing asset and configuration data and map only services with external consumers first
External facilitation or business impact analysis work	One-time, optional	Number of interviews, number of services in scope, and whether the firm also drafts recovery objectives	Agree the interview count and deliverables in writing, and reuse the BIA template for later cycles
Tooling or licenses for the inventory and register	Recurring license fees for commercial tools; one-time setup for self-hosted tools	Choice between commercial GRC or CMDB products and self-hosted open-source platforms, plus hosting and integration work	Self-hosted open-source tools can remove license spend for the register and inventory, but hosting, upgrades and integration remain costs to confirm
Recurring review effort tied to change	Recurring	Frequency of service launches, third-party changes, and changes to customer commitments or contracts	Tie reviews to change management events instead of fixed calendar cycles where the risk profile allows
Interview and analysis labor for recovery objectives	Recurring	Number of critical services, number of recovery scenarios (normal, attack and recovery conditions), and testing needs	Define a standard scenario set and reuse prior analysis where services have not changed
Auditor sampling effort	Recurring per assessment cycle	Number of services sampled, quality of traceability from services to objectives, and evidence availability	Keep one traceable record per service linking stakeholders, impact analysis, objectives and review dates

How CISO Assistant can hold the GV.OC-04 evidence

CISO Assistant can hold the records behind GV.OC-04 in a self-hosted instance, so the lists of critical services, the business impact analysis results and the recovery objectives stay inside your own infrastructure. The project is published under AGPL-3.0-only and ships more than 200 frameworks, including NIST CSF, with audit and compliance assessment features and automatic mapping between frameworks. Start by deciding which objects will represent GV.OC-04 in the tool: the external-facing services and objectives you have identified, the owner of each one, the recovery time objectives you have set for normal, attack and recovery conditions, and the evidence files that prove each objective was reviewed. Your team should then confirm how the tool models services, dependencies, business impact analyses and recovery objectives, because the fields and object types available for these concepts determine how cleanly the records can be linked.

Once the objects exist, record the assessment against the CSF 2.0 Subcategory and link each piece of evidence to it. A practical starting set is the business impact analysis report, the signed list of customer-facing services with their criticality criteria, the recovery objective table approved by the service owners, and the most recent test or exercise record showing those objectives were checked. Assessment results, such as whether the Subcategory is met, partially met or not yet assessed, should carry a date and a named reviewer. Store the files on storage you control and confirm how the instance handles attachments, retention and access logs before loading live data. An independent auditor will still need to see the underlying documents, so the goal is to make them easy to find and trace, not to present the tool's output as an attestation.

Before relying on the instance, have your legal team review the AGPL-3.0-only license terms, particularly what they require if you modify the software and make it available to users over a network. Confirm the tool's current version, support options and upgrade path with its maintainers, and decide who in your organization owns the instance, its backups and its access control. Keep in mind that the software records and organizes your evidence but does not decide whether your critical services are correctly identified. Those decisions remain with your business owners and risk function, and any mapping that the tool displays between frameworks should be checked against the source standards before anyone relies on it for an audit.

Who does what: your team, a partner and the auditor

Your organization owns the decisions that GV.OC-04 is about. Leadership must decide which objectives, capabilities and services external stakeholders depend on, what counts as critical, and how long each service can be unavailable before the impact becomes unacceptable. These choices reflect your mission, contracts and risk appetite, so no outside party can make them for you. Service owners then supply the operational detail that the business impact analysis depends on.

Criticality criteria: Set the thresholds for what makes a service critical, such as customer harm, regulatory exposure or revenue impact, and approve them at an appropriate level of management.
Service owners: Name an accountable owner for each critical service who can state its dependencies, users and operating hours.
Resilience objectives: Decide recovery time objectives and related targets for normal, attack and recovery conditions, and record who approved them.
Acceptable downtime: Make the final call on tolerable outage duration for each service, including trade-offs against cost.
Stakeholder communication: Confirm which customers and partners must be told about the services they rely on, and how.

Before accepting the register, confirm that each objective has a named approver and a review date.

Questions buyers ask about GV.OC-04 cost, effort and outside help

Can our team complete GV.OC-04 in-house, or do we need a partner?

Most organizations can do GV.OC-04 internally, because the work depends on knowledge only insiders hold: which customers, services and deadlines matter most and how long each can be unavailable. The outcome is that the critical objectives, capabilities and services external stakeholders rely on are understood and communicated. Your risk, operations and IT teams usually own the business impact analysis, the criticality criteria and the recovery objectives. A partner becomes useful when no one has run a business impact analysis before, when staff lack time for workshops, or when you want an outside reviewer to test the results. The organization keeps ownership of every decision and approval either way. Confirm internally whether these teams have the capacity to run workshops and sign off results before you commit to a scope.

What work do executives and service owners need to provide?

Executives and service owners provide the business input, and the technical teams turn it into documented objectives. In practice, the work splits into three parts:

Executives confirm the mission-critical objectives, approve the criticality criteria and accept the resilience objectives that the organization will be measured against.
Service owners describe each service, the customers and partners who depend on it, its upstream dependencies, and how the business is affected as the outage lengthens.
Risk and IT leaders keep the recovery objectives current and arrange tests that show whether systems can meet them.

The time each group spends depends on how many services are in scope and how many approval rounds your governance requires. Ask for the expected workshop schedule and named reviewers in any written quote.

How long does GV.OC-04 take, and what drives the timeline?

The duration depends mainly on the scope, so no single timeline applies to every organization. The biggest drivers are the number of services and external stakeholders in scope, whether a current business impact analysis already exists, and how quickly service owners can answer questions. Approval cycles matter too, especially when the board or a regulator must review the resilience objectives. Recovery time objectives that have never been tested usually take longer, because the team must measure real restoration times before the figures can be trusted. Ask the partner for a milestone plan that lists the workshops, reviews, approvals and tests, and confirm which of these depend on your staff or on a vendor. Use the cost-to-meet table on this page to compare the effort behind each step.

Does NIST certify that we meet GV.OC-04?

No. NIST does not certify organizations, and it does not endorse CSF-related products, implementations or services. NIST has also stated it has no plans for a conformity assessment program for the CSF. NIST is a standards body rather than a regulator, and most organizations use the CSF voluntarily. Some customers or suppliers require it, and U.S. federal agencies have been required to use it since a 2017 executive order. That means any claim that you align with GV.OC-04 rests on your own documented evidence. If a customer or regulator wants independent assurance, you must engage an assessor or auditor that the requesting party accepts. Read the NIST Cybersecurity Framework FAQs before you put alignment language in a contract.

What will an assessor sample when reviewing GV.OC-04?

The assessor chooses the sample and method under the terms of its engagement, so confirm the approach in writing before fieldwork starts. Typically, the review traces a small number of services from the business impact analysis through to the recovery objectives and their test results. Evidence commonly includes the current analysis, the written criticality criteria, the list of services that external stakeholders rely on, recovery objectives for normal, attack and recovery conditions, records of approval, and evidence that stakeholders were told about the commitments. The assessor will also check whether the objectives were reviewed after significant change. Ask whether the assessor will select services at random or by risk, and whether it expects evidence from tests that you ran or from tests it observes. DeployOpen prepares these records but does not issue audit reports or attestations.

What should we ask a partner to include in a written, fixed-scope quote?

Ask for a quote that states the scope, deliverables, responsibilities and assumptions before any work begins. DeployOpen works to fixed-scope engagements agreed in writing, does not publish a price list, and prepares its quote from that written scope. A useful quote lists the services and stakeholder groups in scope, the deliverables such as the impact analysis, criticality criteria, resilience objective register and evidence index, and the workshops and approvals the organization must supply. It should separate one-time work from recurring items, such as periodic reviews or a retainer, and state what triggers a change request. Confirm that exclusions are listed, including any independent assessment, which an auditor or assessor performs. Also ask for the milestone plan and the named people responsible for each deliverable.

How DeployOpen works on this

DeployOpen scopes, builds and documents the systems and records that show which critical services others depend on, and how quickly they must come back. We prepare the evidence inside your own infrastructure, and your organization owns the decisions about criticality and recovery objectives. Independent auditors, not DeployOpen, assess and report on the outcome.

How we scope

Written scope agrees which services, customers and external stakeholders are in the GV.OC-04 review before work starts.
Scope lists the business impact analysis inputs, such as service inventories and stakeholder dependency records, that we will prepare.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build begins.

How we build

We configure self-hosted platforms that record service criticality tiers, owners and the external parties relying on each service.
We set up documented recovery time objective fields for normal, attack and recovery conditions, aligned to your decisions.
We test that the platform's records can be exported and reviewed, so an assessor can trace a service to its stakeholders.

How we hand over

Handover includes the criticality criteria, business impact analysis records and resilience objectives your team approved.
We document how each record maps to GV.OC-04 and the related ISO/IEC 27001:2022 clause and controls, for your own review.
Your staff receive runbooks explaining how to update service dependencies and objectives as customer expectations change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
A retainer can keep dependency inventories and recovery objectives current as services, contracts and customers change.
Confirm with us in writing which evidence and review cycles your assessor expects before agreeing the retainer scope.

GV.OC-04 Critical services others depend on