← All Blogs

The exception register: risks someone accepted on your behalf

By Best IT MSP Editorial Team - Updated October 21, 2026 - 14 min read

The Best IT MSP editorial team maintains this directory's provider data across the US and Canada. We rank providers on verified rating and firmographic data, label paid placement, and do not sell IT services.

What is a risk exception register?

A risk exception register is the written list of risks your organization has decided not to fix, with a reason, a compensating control, a named owner and an expiry date recorded against every line.

Every IT environment has one. Yours exists whether or not anyone wrote it down. The server that cannot reboot during business hours. The line-of-business application that breaks on the current version. The two machines running an operating system past end of support because a machine tool needs them. Somebody accepted each of those risks. The question is who, when, and for how long.

NIST treats acceptance as one of five formal risk responses and defines the category as an intentional and informed decision and actions to accept, avoid, mitigate, share, or transfer an identified risk. Read that slowly. Intentional, and informed. A risk nobody recorded was neither. NIST also defines a risk register as a central record of current risks, and related information, for a given scope or organization, and states that current risks include accepted risks alongside risks with a planned mitigation path. Accepting a risk does not take it off the list. It moves it to a different column.

This is a different document from the three it sits beside. Your patch compliance rate is a measurement. Your IT asset register is an inventory. Your end-of-life software list is a condition report. The exception register is a record of decisions, and it is the only one of the four that names a person. What those decisions leave behind is what NIST calls residual risk, the portion of risk remaining after controls have been applied. Residual risk is yours whether you signed for it or not.

Who is supposed to sign a risk acceptance?

To accept a risk properly, the person who signs must hold the authority to carry the consequence. In federal practice that person has a title. NIST calls them the authorizing official, and defines the role as a senior Federal official or executive with the authority to authorize (i.e., assume responsibility for) the operation of an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation).

The point of the title is accountability rather than paperwork. NIST's own description of the authorize step says it exists to provide accountability by requiring a senior official to determine if the security and privacy risk based on the operation of a system or the use of common controls, is acceptable. A senior official. Not the engineer who hit the error, and not the account manager who wanted the ticket closed.

You are not a federal agency, so look at how a financial regulator writes the same rule for private firms. New York's cybersecurity regulation requires encryption of nonpublic information at rest, then handles the exception explicitly. Where a firm determines that encryption at rest is infeasible, it may instead secure such nonpublic information using effective alternative compensating controls that have been reviewed and approved by the covered entity's CISO in writing. The feasibility and the effectiveness both get reviewed by the CISO at least annually.

Three things do the work there. The exception is allowed, it needs a named alternative control, and a specific officer approves it in writing and re-approves it annually.

CISA's performance goals ask for the same thing in plainer language. Goal 1.A wants roles, responsibilities, and authorities related to the organization's cybersecurity program established and documented in policy. Authorities is the word to notice. In a 30-person company there is no CISO and no authorizing official, so the authority sits with the owner, the finance director or the operations lead. Accepting risk is the one part of the job your provider cannot legitimately do for you, because they do not carry the loss.

Your provider can recommend an exception. Only you can accept one, because only you own the consequence of it being wrong.

Six entries that are probably already on your register

Six exceptions appear in almost every small-business estate, and only one of them is about patching. Expect to find each of these when you ask.

• The server nobody will reboot. A patch is installed but inactive until restart, so the machine reports as patched and is not. Payroll, the shared drive and the phone system are the usual candidates.
• The application that breaks on the current version. The vendor certified version 9, your software runs on version 7, and nobody wants to own the upgrade budget.
• The unsupported machine controlling a machine. A workstation driving a CNC mill, a laser cutter or a medical device, running an operating system the vendor abandoned years ago.
• The multi-factor authentication exemption. One service account, one scanner mailbox, or one director who found the prompts annoying. Exemptions are legitimate. Unwritten ones are not.
• The firewall rule opened for a project. Remote access for a contractor who finished in 2023, still live because closing it needs someone to confirm nothing depends on it.
• The local administrator rights nobody removed. Granted to make one install work, never withdrawn, and now the default on a dozen laptops.

That spread is why an exception register is not a patch management artifact. Four of those six have nothing to do with a missing update. They are identity, network and change management decisions, usually tracked in four different places, which in practice means none.

The exposure behind those lines is measurable. CISA's Known Exploited Vulnerabilities catalog, the official list of flaws confirmed as used in real attacks, held 1,754 entries when we checked it on October 21, 2026. Verizon found only 26 percent of critical vulnerabilities in that catalog were fully remediated in 2025, down from 38 percent, at a median 43 days to fully resolve one. Those are the flaws attackers already use, and roughly three quarters stayed open.

What a compensating control has to prove

A compensating control has to deliver protection equivalent to the control it replaces, not merely something adjacent to it. NIST's definition sets that bar directly. A compensating control is one employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system.

The health privacy rule turns that into an obligation most SMBs already live under. HIPAA labels each implementation specification either required or addressable. Where an addressable one is not reasonable and appropriate, the organization must document why it would not be reasonable and appropriate to implement the implementation specification and implement an equivalent alternative measure if reasonable and appropriate. The rule also grants real latitude on how, listing the size, complexity, and capabilities of the organization and the costs of security measures among the factors it must weigh.

Addressable does not mean optional. It means you may substitute, provided you write down the reasoning. A covered dental practice that skips encryption and records nothing has not used the flexibility the rule offers. It has simply failed the rule, and the written record is the only thing that distinguishes the two.

The machine tool case, in CISA's own words

CISA names the exact scenario in your workshop. Its vulnerability management goal asks organizations to track risk response through a plan of action and milestones (POA&M), risk registers and risk detail reports, and to add compensating controls for legacy systems where possible. Where patching is either not possible or may substantially compromise availability or safety, it recommends compensating controls such as segmentation and monitoring, recorded as such, and says the asset should be made inaccessible from the public internet. So segment the network, monitor the segment, and write both down. A promise to keep an eye on it is not a compensating control.

The federal cloud program shows what the same judgment looks like when it is graded. FedRAMP sorts these claims into three kinds. A false positive (FP) occurs when a vulnerability is identified that does not actually exist on the system. A risk adjustment (RA) is a reduction in the scanner-defined risk level of a vulnerability. An operational requirement is a finding that cannot be remediated, often because the system will not function as intended, which is your unpatchable machine tool in federal language. Each needs separate approval, and only the first one actually goes away.

Why every entry needs an expiry date, not a review promise

An exception with no expiry date is a permanent change recorded as a temporary one. Set a date and the entry returns for a decision. Leave it open and the decision was made once, by one person, and never revisited.

Published standards put numbers on this. A defense contractor granted a conditional CMMC status must have its plan closed and confirmed by a POA&M closeout assessment within 180 days of the status date, or the status expires. FedRAMP is tighter still on remediation, giving 30 days for critical and high findings, 90 days for moderate and 180 days for low from discovery. Those are the published clocks. Compare them with the exception on your own register that has no date at all.

Left alone, exposures do not drift shut. Verizon ran a survival analysis on 7,513 third-party cloud-based multi-factor authentication exposures and measured how many were still unresolved over time. At day 7, 58 percent were still open. At day 28, 50 percent. At day 90, 42 percent. At day 240, 32 percent were still unresolved. Eight months after discovery, nearly a third of a known, named, specific exposure class had not been closed. No entry on anybody's register said eight months. The date was just never set.

Now set the review cadence against the attacker's clock. Sophos reported median dwell time declining to three days across 661 incident response cases handled over twelve months. An annual review of your exception register runs 365 days. The attacker needs three. That gap does not mean the annual review is worthless, because it is how a temporary entry stops becoming permanent. It means the review is governance, not defense, and the compensating control is the only thing doing defensive work in between.

End-of-life software is the clearest test of whether a date was ever set. Microsoft ended Windows 10 support on October 14, 2025 and no longer provides software updates, security fixes, or technical assistance to those machines. The consumer extended-security route runs to October 12, 2027 and excludes devices managed by an organization. If business machines in your office still run Windows 10, that is a budget decision rather than a patching failure, and it needs a register line with a replacement date, an owner and a compensating control until then.

Some risks cannot be accepted at all

Three published rule sets refuse acceptance outright for certain findings, which is the part of this subject almost nobody tells a buyer. An exception register is not a universal escape hatch. Some lines are simply not available to sign.

The Pentagon's rules name them. Under the CMMC program, a POA&M is not permitted at any time for Level 1 self-assessments, and at Level 2 a plan may only hold requirements where none of the security requirements included in the POA&M have a point value of greater than 1. Specific controls are excluded by name, including the system security plan itself and physical access logs. Translated out of federal language, some controls are so foundational that a promise to fix them later is not an acceptable answer.

FedRAMP draws a similar line by severity. Its guidance states plainly that FedRAMP will not approve an OR for a High vulnerability; however, CSPs may mitigate the risk. A high-severity finding on a cloud service cannot be parked as an operational requirement. It can be mitigated, which is a different claim requiring different evidence. The same guidance settles what an approved exception is worth on paper: approved ORs are still considered open risks, kept on the open tab and periodically reassessed. An accepted risk does not leave the books. It changes who is answerable for it.

CISA is blunter about products that cannot be fixed. For every vulnerability in its catalog, agencies must apply updates per vendor instructions or remove from agency networks if the impacted product is end-of-life or cannot be updated otherwise, and CISA strongly encourages all organizations to do the same. Remove, not monitor. For a confirmed exploited flaw in unsupported software, decommission is the recommended answer and the register entry should carry a decommission date.

HIPAA uses the same structure. A specification marked required gets implemented; only an addressable one can be substituted. So the practical test for your register has two steps. Ask whether the control is mandatory under a rule that binds you, and whether the flaw already sits in the exploited catalog. A yes to either means the honest entry is a remediation date, not an acceptance.

The honest no beats the invented date

Disclosing a gap protects you. Inventing the date you will close it does not. The Justice Department announced that Pennsylvania State University agreed to pay $1,250,000 to resolve allegations that it violated the False Claims Act across fifteen contracts or subcontracts involving the Department of Defense or NASA. The United States alleged the university submitted cybersecurity assessment scores to DoD that reflected it had not implemented certain controls, but misrepresented the dates by which it would implement them and did not pursue plans of action to do so. The settlement resolved allegations and made no determination of liability.

Read the two halves. Not implementing the controls was disclosed and was survivable. The dates were the problem, and so was the absence of any plan behind them. A register with honest dates and visible progress is a defense. A register with optimistic dates and no activity is worse than no register, because it documents that you knew.

A regulator has written the honest no into law. New York gives covered firms a choice each April. File a certification of material compliance, or file a written acknowledgment that acknowledges that, for the prior calendar year, the covered entity did not materially comply, identifies all sections of this Part that the entity has not materially complied with, and provides a remediation timeline or confirmation that remediation has been completed. Either filing must be signed by the covered entity's highest-ranking executive and its CISO.

Note what the regulator did not do. It did not ask for perfection, and it did not offer a quiet third option. You either comply or you name the gap, the timeline and two signatures. Firms keep the supporting records for five years, including remediation plans and timelines for their implementation. That is an exception register with a retention schedule attached, and a reasonable model even for a business New York has never heard of.

How to ask your provider for your exception register

To get your exception register, send one email asking for the list by a named date, in a named format, with the five fields below. A provider who operates the control replies in a day, because the data already sits in their ticketing system. A provider who does not will offer a meeting. The delay is the finding.

• Asset and risk. What the exception covers and what could go wrong, in one line each, naming the system rather than a tool.
• Reason. The legitimate technical or business constraint that stops the fix, stated as a fact rather than a preference.
• Compensating control. What is in place instead, and how someone could verify it is working this week.
• Named owner. A person at your business, not a team and not your provider, who accepted the risk and is accountable for closing it.
• Expiry date. The date the entry returns for a decision, with a note of how many times it has already been renewed.

The renewal count is the field to read first. One renewal is normal operations. Four renewals on the same entry is a decision the business keeps declining to make, dressed up as a process. Sort the register by renewal count and you have a prioritized list of your real IT problems, produced without a single scan.

Then change three things in the agreement rather than the proposal. Require the register as a named deliverable in the service level agreement, refreshed monthly alongside the patch report. Require a quarterly review meeting where each entry is closed, renewed with a fresh expiry date, or escalated to a decommission plan. And require that no entry is created without a named owner on your side, which forces the conversation at the moment the exception is made rather than a year later.

The arithmetic favors doing this. IBM puts the global average cost of a data breach at USD 4.99 million and the average time to identify and contain an active breach at 247 days. Reading your own exception register costs an email and an hour. None of this buys perfect security, and no honest provider offers it. It buys a documented, dated, owned record of the risks already running in your business, and the ability to say yes or no to each one yourself. CISA asks organizations to identify, record, assess, prioritize and monitor the risks posed by a managed service provider. For the evidence layer underneath this, read our guide to the audit evidence nobody collects.

FAQ

What is a risk exception register?

A risk exception register is the written list of risks an organization has decided not to fix, with a reason, a compensating control, a named owner and an expiry date on each line. NIST defines risk response as an intentional and informed decision to accept, avoid, mitigate, share or transfer a risk.

Who should sign off a risk acceptance in a small business?

The person who carries the loss signs, which in a small business means the owner, finance director or operations lead. NIST reserves the decision for a senior Federal official or executive with the authority to authorize a system's operation. New York requires alternative compensating controls to be reviewed and approved by the covered entity's CISO in writing.

How long should a security exception last?

Set a date and keep it short. The CMMC program requires a plan of action to be confirmed by a POA&M closeout assessment within 180 days, and FedRAMP allows 30 days for critical and high findings from discovery. Quarterly review with a hard expiry date works for most small businesses.

What is the difference between an exception register and a POA&M?

A plan of action and milestones is a fix with a schedule. An exception is a risk accepted without a fix. NIST defines a POA&M as a document that identifies tasks that need to be accomplished with milestones for meeting the tasks, and the scheduled completion dates for the milestones. Both belong on one register.

Can my MSP accept a risk on my behalf?

No, not legitimately. A provider can recommend an exception and operate the compensating control, but acceptance requires authority to carry the consequence, which sits with you. CISA asks organizations to document roles, responsibilities, and authorities related to the organization's cybersecurity program. Ask who signed each entry on your register and check the name is yours.

← All Blogs