GV.OC-04 says critical objectives, capabilities and services that external stakeholders depend on or expect from the organization are understood and communicated. Put simply: know which of your services customers cannot do without, and tell the right people how quickly you intend to bring them back.
What good looks like
You have a short list of critical services, ranked by impact if they stop. Each has a recovery time objective and an owner. Support, engineering and leadership all quote the same numbers. Customers hear the same story in contracts and status pages that your internal runbooks use.
How to implement it
- Define criticality criteria. Customer impact, revenue at stake, legal duty and the number of people affected are common ones.
- Run a light business impact analysis. For each service, ask what breaks and what it costs after one hour, one day and one week.
- Set resilience objectives, such as a recovery time objective, for normal operation, under attack and during recovery. Be honest. A target you cannot hit is worse than a looser one you can.
- Communicate them. Publish what you can on your status page or trust page, put the rest in internal runbooks, and make sure contracts do not promise more.
- Test one objective a year with a restore or failover exercise.
Evidence to collect
- The ranked list of critical services with criteria and owners.
- The business impact notes behind the ranking.
- Documented recovery objectives and a record of at least one test against them.
- Customer facing statements that match the internal numbers.
Common gaps
- Everything is called critical, so nothing is prioritized.
- Recovery targets are copied from a template and never tested.
- Sales promises an uptime figure that engineering has never seen.
- Dependencies of the critical service, such as a payment provider, are left off the analysis.
Example resilience objectives
A small billing platform might set these: the customer API returns to service within one hour in a normal outage, within four hours if under attack, and the invoicing batch job can wait one business day. The internal admin tool is rated low and can be down for a week. Writing the numbers down forces a useful argument about why the API outranks the admin tool, and it tells engineering where redundancy money should go.
Who needs to hear it
Resilience objectives only help if people act on them. Incident responders need them to triage. Account managers need them so they do not promise more than the platform can deliver. Leadership needs them to judge whether a recovery is on track. Put the numbers in the incident runbook header, in the customer contract template and on the page your support team reads from.
Quick check
How many critical services should a small company list?
Usually three to seven. If the list is longer, your criteria are probably too loose.
What if we have never tested recovery?
Start with one service and a restore from backup in a test environment. Record how long it took. That is your first real number.
Sources
- NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.OC-04: https://csrc.nist.gov/projects/cybersecurity-framework/filters
- NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework
The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.
