Category: Continuous Monitoring

Deviation Reporting

Also known as: Non-conformance Reporting, Deviation Report, Non-conformance Report

Simply put

Deviation reporting is the practice of documenting and communicating any departure from an established procedure, standard, protocol, or requirement. The report captures what happened, records the departure from the expected process, and generally supports tracking and follow-up. The specific reporting triggers, timelines, and recipients vary significantly by the governing framework or oversight body, so readers should confirm the requirements that apply to their context.

Formal definition

Deviation Reporting refers to the structured recording, assessment, and communication of any identified departure from an applicable standard procedure, protocol, or requirement, often captured in a document also known as a Non-conformance Report. In practice, reporting obligations are defined by the governing authority or program and typically specify what constitutes a reportable deviation, the applicable timelines, and the responsible oversight recipient. The evidence available describes deviation reporting in contexts outside defense cybersecurity compliance, for example, FDA-regulated biological product deviations, which a manufacturer is generally required to report as soon as possible but not later than a specified number of calendar days, and clinical research protocol deviations, where reporting to an oversight body such as an Institutional Review Board (IRB) may be required only for deviations that harmed a subject or placed a subject at risk, with major deviations submitted within a defined number of business days of discovery. These specific triggers, thresholds, and timelines are program-specific and non-transferable; the evidence does not establish equivalent requirements for CUI, DoD RMF, FedRAMP, or CMMC contexts, and practitioners should verify the deviation reporting requirements defined in their applicable authoritative source, contract, or agency guidance rather than assuming a uniform standard applies.

Why it matters

Deviation reporting is the mechanism that turns an unplanned departure from an established procedure into a documented, traceable, and actionable record. Without it, a departure from a standard process may go unexamined, leaving an organization unable to demonstrate that it recognized the deviation, assessed its impact, and took corrective action. For compliance officers and auditors, the deviation report is often the artifact that shows whether a control was actually operating as intended or whether an exception occurred that requires follow-up. It supports accountability by preserving what happened and where the process diverged from expectation.

A critical point for practitioners is that reporting triggers, timelines, and recipients are defined entirely by the governing framework or oversight body, and they are not interchangeable across domains. The evidence illustrates this variability: in the FDA-regulated biological product context, a manufacturer is generally required to report deviations as soon as possible but not later than a specified number of calendar days, while in clinical research, reporting a protocol deviation to an oversight body such as an Institutional Review Board may be required only when a deviation harmed a subject or placed a subject at risk, with major deviations submitted within a defined number of business days of discovery. These thresholds and clocks are program-specific and cannot be assumed to carry over from one regime to another.

For defense and public sector cybersecurity work, the practical implication is caution: the evidence available describes deviation reporting in contexts outside defense cybersecurity compliance and does not establish equivalent triggers, thresholds, or timelines for CUI handling, DoD RMF, FedRAMP, or CMMC environments. Practitioners should not treat a deviation reporting standard borrowed from a different regulatory domain as authoritative for their own program. Instead, they should confirm the deviation or non-conformance reporting requirements defined in their applicable authoritative source, contract, or agency guidance.

Who it's relevant to

Compliance Officers and Auditors

Deviation and non-conformance reports are often the primary evidence that an organization recognized a departure from an established procedure and responded to it. Compliance and audit staff rely on these records to verify whether controls operated as intended and whether exceptions were identified, assessed, and tracked. They should confirm which reporting triggers and timelines apply under their specific governing framework rather than assuming a single cross-domain standard.

Information System Security Managers and Program Staff

Personnel responsible for maintaining system procedures need clear internal processes for capturing and escalating departures from established protocols. The evidence does not establish deviation reporting requirements specific to DoD RMF, FedRAMP, CMMC, or CUI environments, so security managers should verify what their applicable authoritative source, contract, or agency guidance actually requires before defining reportable-deviation criteria and timelines.

Quality and Manufacturing Practitioners in Regulated Domains

In regulated manufacturing and research settings, deviation reporting carries program-specific obligations. For FDA-regulated biological product deviations, a manufacturer is generally required to report as soon as possible but not later than a specified number of calendar days. In clinical research, reporting to an oversight body such as an IRB may be required only for deviations that harmed or placed a subject at risk, with major deviations submitted within a defined number of business days of discovery. Practitioners should confirm the exact thresholds and clocks in their governing text.

Government Contractors

Contractors operating across multiple regulatory regimes should avoid transferring a deviation reporting standard from one domain to another. Reporting triggers, timelines, and recipients are defined by the governing authority or program and are non-transferable. Contractors should verify the deviation or non-conformance reporting obligations stated in their specific contract and applicable agency guidance.

Inside Deviation Reporting

Deviation Identification

The documentation of a specific instance where an implemented control, configuration, or process departs from an approved baseline, standard, or authorized security requirement. In most frameworks, this includes identifying the affected control or requirement, the system or component involved, and the nature of the departure.

Justification or Rationale

The recorded basis for the deviation, such as operational necessity, technical infeasibility, or compensating measures. Reviewers generally require this to evaluate whether the deviation is acceptable and whether residual risk remains within tolerance.

Risk Assessment of the Deviation

An analysis of the impact the deviation has on the security posture and residual risk of the system. This typically informs whether an authorizing official can accept the deviation and under what conditions.

Compensating or Mitigating Controls

Alternative measures put in place to offset the risk introduced by not meeting the original requirement as specified. Documentation generally describes what these measures are and how they address the underlying control objective.

Approval and Disposition

The record of who reviewed the deviation, the decision made (accept, reject, remediate), and any conditions or time limits attached. Authority for accepting risk generally rests with a designated official such as an authorizing official, subject to agency-specific policy.

Tracking and Remediation Timeline

Where a deviation is intended to be temporary, documentation generally includes planned corrective actions and target dates, so the deviation can be revisited during continuous monitoring rather than treated as a permanent state.

Common questions

Answers to the questions practitioners most commonly ask about Deviation Reporting.

Does approving a deviation mean the underlying risk has been eliminated?

No. A deviation approval generally documents that an authorizing official or designated authority has accepted or acknowledged a departure from a required control, configuration, or baseline, not that the associated risk has been removed. Compliance acceptance and security are distinct: the risk typically persists and remains subject to continuous monitoring, tracking through a plan of action and milestones (POA&M) where applicable, and reassessment. Confirm the specific handling requirements against your organization's current authorizing documentation.

Is a documented deviation a permanent exception once it is approved?

Generally no. Deviations are typically time-bound and tied to the conditions under which they were approved, much as an Authority to Operate is not permanent but subject to continuous monitoring and reauthorization. In most implementations a deviation is revisited on a defined interval, upon changes to the system or environment, or when the justifying condition changes. Treating an approved deviation as an indefinite waiver is a common mistake; verify expiration, review, and renewal terms in your governing policy.

Who has the authority to approve a deviation?

Approval authority generally rests with a designated official identified in the applicable authorization or risk management process, such as an authorizing official (AO) under the RMF, and may involve the information system security manager or other risk executives depending on the deviation's scope and residual risk. The specific approval chain varies by agency, program, and whether the system handles CUI, classified information, or falls under civilian FISMA versus DoD authorities. Confirm the delegated authority against your organization's current policy and authorization boundary documentation.

What information should a deviation report typically include?

In most implementations a deviation report identifies the specific control, requirement, or baseline being departed from; the reason or justification for the deviation; the affected systems or components; any compensating or mitigating measures; the residual risk; and the approving authority with associated dates and review conditions. Exact content and format are usually defined by the governing framework or agency template, so verify required fields against your current authoritative process documentation rather than assuming a universal standard.

How does deviation reporting relate to a plan of action and milestones (POA&M)?

The two are related but distinct. A deviation generally documents an accepted or acknowledged departure from a requirement, while a POA&M typically tracks identified weaknesses along with planned corrective actions, resources, and milestones for remediation. Depending on the framework and agency practice, a deviation may be paired with a POA&M entry when remediation is expected, or handled as an accepted risk when it is not. Confirm the intended relationship in your applicable guidance, since usage varies across programs and revisions.

How often should approved deviations be reviewed?

Review frequency is generally set by organizational policy and the continuous monitoring strategy rather than by a single fixed interval that applies everywhere. Deviations are commonly reassessed on a defined periodic basis, at the deviation's stated expiration, and when triggering events such as system changes, environment changes, or changes to the justifying condition occur. Because intervals and triggers are tailored by agency and program, verify the specific review cadence against your current authoritative documentation.

Common misconceptions

A documented and approved deviation permanently resolves the underlying gap.

A deviation record generally reflects an accepted or pending condition at a point in time, not a permanent exemption. Because authorizations are time-bound and subject to continuous monitoring, deviations are typically revisited, and many are expected to be remediated or re-justified over time. Practitioners should confirm the applicable agency's requirements.

Reporting a deviation is the same as demonstrating that the system remains secure.

Documenting a deviation records the departure and its accepted risk; it does not by itself establish that the system is secure. Compliance documentation and security posture are distinct, and a deviation may signal residual risk that requires ongoing management even after approval.

Any team member can accept the risk of a deviation once it is written down.

Risk acceptance authority is generally reserved for a designated official, such as an authorizing official under the RMF, rather than any individual who identifies the deviation. The specific approval authority and process depend on the governing framework and agency-specific policy, which the reader should verify against current authoritative sources.

Best practices

Tie each deviation to the specific control, requirement, or baseline it departs from, and cite the governing publication or standard so reviewers can trace the departure to its authoritative source.

Include a documented risk assessment and clearly describe any compensating or mitigating controls, so the accepting official can make an informed, risk-based decision rather than a purely administrative one.

Route deviations to the appropriate approval authority for the applicable framework, and confirm that authority against current agency-specific policy rather than assuming a uniform process across federal civilian, defense, and national security systems.

Treat approved deviations as time-bound conditions by assigning remediation timelines and revisiting them during continuous monitoring, rather than filing them as permanent exemptions.

Maintain an auditable record of each deviation's identification, justification, disposition, and approver, so the documentation can support assessments, authorization reviews, and audits.

Verify deviation reporting formats, thresholds, and escalation requirements against the current authoritative text for your environment, since these details can vary by revision, impact level, and agency tailoring.