GV.OC-03 says legal, regulatory and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed. The outcome is a working process, not a one time list. You know which rules and promises apply to you, someone tracks changes, and your security plan reflects them.
What good looks like
A single register lists each obligation, where it comes from, who owns it and how you meet it. Privacy laws that cover personal data you hold sit next to contract clauses such as breach notice windows, audit rights and data location limits. When a new contract arrives, security and legal both see the clauses that touch security before signature.
NIST's own examples for this outcome are specific: set up a process to track legal and regulatory requirements for protecting individuals' information, a process for contractual requirements covering supplier, customer and partner information, and align your cybersecurity strategy with both.
How to implement it
- Start with data. List the kinds of personal and customer data you handle and the jurisdictions your customers and staff sit in. That tells legal which laws are in scope.
- Build the obligations register. One row per obligation: source document, clause or section, plain language summary, owner, control or process that satisfies it, last reviewed date.
- Pull contract security terms into the same register. Look for breach notice deadlines, subprocessor rules, encryption requirements, right to audit and insurance minimums.
- Add an intake step. Sales or procurement flags any contract with nonstandard security terms before it is signed.
- Assign a review rhythm. Quarterly is enough for most small companies, plus a check when you enter a new market or take a new data type.
- Feed gaps into the risk register so they get owners and dates.
Evidence to collect
- The obligations register with owners and review dates.
- The contract intake checklist and examples of it being used.
- Records showing a changed rule led to a changed policy or control.
- Legal or outside counsel confirmation of which laws apply, kept as a dated note.
Common gaps
- The register exists only in legal's head, so engineering never sees it.
- Contract terms are agreed by sales and forgotten, then a breach notice window is missed.
- Obligations are listed but not mapped to a control, so nobody can show how they are met.
- Review happens once, at the start.
Mapping obligations to controls
The hard part is the middle column: which control satisfies which obligation. A tool that holds obligations, controls and evidence in one place makes this less manual. The demo below walks through mapping a requirement to controls and the evidence behind them.
A worked example
Take a ten person software company that sells to hospitals and to European retailers. Its register has a row for a hospital customer contract that requires breach notice within 72 hours, a row for a retailer contract that restricts where customer data may be stored, and a row for the privacy law that covers European personal data.
Each row names an owner. The breach notice row points to the incident response plan and the on call rota. The data location row points to the cloud region settings and a quarterly check that nothing was copied elsewhere. The privacy law row points to the data inventory and the process for answering data subject requests.
Nothing here needs special software. It needs one table, three owners and a calendar reminder. What it buys is the ability to say, when a customer asks, exactly which obligations you track and how you meet each one.
Keeping it alive
A register decays fast unless it is tied to events. Link it to three triggers: a new contract with security terms, a new product or data type, and a legal change flagged by counsel or a trade body. When one fires, someone updates the row and the linked control, and the review date moves. Run a short quarterly meeting to close open rows and retire ones that no longer apply.
Privacy and civil liberties
The outcome names privacy and civil liberties obligations explicitly. For most companies this means knowing what personal data you hold, why you hold it, how long you keep it and who it is shared with. If you cannot answer those four questions for each system, the obligation is not yet managed, however good the policy looks on paper.
Questions customers and auditors ask
Expect three questions. Which laws and contract terms apply to you, and who tracks them? How do you hear about changes? Show me one obligation and the evidence that you meet it. If your register answers all three in minutes, the outcome is in good shape. If answering takes a week of email, the process is not yet real, whatever the policy says.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the CSF tell me which laws apply to me?
No. It asks you to find out and manage them. Counsel or your compliance lead decides applicability.
Is a spreadsheet enough?
Yes, if it has owners, dates and links to the controls and evidence. The format matters less than keeping it current.
Sources
- NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.OC-03: 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.
