Can I remove controls from a NIST baseline?

Yes, you can remove controls from a NIST baseline, but only through a structured tailoring process with clear justification, traceability, and approval. NIST baselines (for example in NIST SP 800-53) are starting points, not mandatory one-size-fits-all sets. However, in regulated industrial environments you should assume that any removed control will be scrutinized by internal audit, customers, and potentially regulators.

What “removing a control” actually means

In NIST terminology you generally do not delete a control outright. Instead you:

• Tailor the baseline by marking a control as “not applicable,” “not selected,” or “implemented via alternative control,” and
• Document the rationale so someone else can understand why that control is not required for your system or environment.

The original NIST baseline remains your reference; your organization maintains a tailored baseline that adds, modifies, or removes specific controls for the defined system or information type.

When is it acceptable to remove a control?

It is generally acceptable to remove or exclude a baseline control when at least one of the following is true:

• Clear non-applicability: The control addresses a risk that cannot arise in your system (for example, a control about public-facing services when the system is fully isolated and has no external interfaces, and that isolation is itself controlled and verified).
• Compensating or alternative control: You address the same risk through other controls that are equal or stronger (for example, using a hardware-enforced security boundary instead of a software-based control, with documented mapping).
• Higher-level organizational control: The risk is fully handled by enterprise services outside the local system boundary (for example, centralized identity and access management already enforces the requirements).

In all cases, the decision has to be risk-based, documented, and tied to the defined system boundary and data classification.

Minimum safeguards if you remove a control

If you tailor out a NIST control, you should at minimum have:

• Clear scope definition: A documented system boundary and information types (for example, OT network segments, MES, historian, ERP interfaces).
• Risk analysis: A written assessment showing why the specific risk is low, mitigated elsewhere, or not applicable.
• Tailoring record: A maintained record of each removed control, status (for example, Not Applicable), and justification.
• Approval workflow: Formal sign-off from the accountable roles (often CISO, system owner, risk management, and sometimes quality/regulatory for GxP or aerospace work).
• Change control: Any future change to architecture, connectivity, or data flows triggers a review of those tailoring decisions.

Specific considerations in industrial and regulated environments

In mixed IT/OT and manufacturing environments, removal of NIST controls has extra complications:

• Brownfield systems: Many OT assets and MES/ERP layers are legacy. You may be tempted to mark controls as “not applicable” simply because implementation is hard or vendor support is weak. That is risky. Difficulty alone is not a credible justification.
• Shared controls: A removed control at the plant level may be assumed to be present at the enterprise level (for example, log retention, incident response). Coordination with corporate IT and security architecture is required.
• Validation and qualification: In life sciences, aerospace, and similar sectors, controls may be embedded in validated systems. Tailoring out a control can trigger revalidation or requalification. This cost and risk should be part of the decision.
• Customer and regulator expectations: Customers may reference specific NIST controls in contracts or supplier cybersecurity requirements. You can tailor, but you must be able to defend each removal with evidence.

How to tailor a NIST baseline responsibly

A practical process for tailoring in a manufacturing context typically includes:

1. Identify the baseline: Select the relevant NIST baseline (for example, Moderate from NIST SP 800-53 or NIST CSF profiles aligned to your sector).
2. Define the system and data: Document the system boundary, connections to MES/ERP/PLM/QMS, and data types (such as ITAR-controlled technical data, quality records, production recipes).
3. Review each control: For each control, decide whether to keep, enhance, or propose removal/compensation.
4. Document justification: Capture for any removed control: reason, supporting evidence, reference to risk assessment, and mapping to compensating controls if applicable.
5. Obtain approvals: Route the tailored baseline through your defined governance (security review board, change control board, or equivalent).
6. Integrate with existing systems: Reflect the final tailored set in your policies, procedures, OT/IT configurations, and any automated monitoring or GRC tooling.
7. Maintain traceability: Keep a traceable link between the original NIST baseline and your tailored baseline so auditors can see exactly what changed and why.

Why “full replacement” of NIST baselines tends to fail

Some organizations try to replace the NIST baseline entirely with a homegrown control set. In long-lifecycle, regulated manufacturing this usually fails or becomes very costly because:

• Qualification and validation burden: You must show that your custom set is at least equivalent from a risk perspective. This is hard to justify without referencing a recognized baseline.
• Integration complexity: Vendors, partners, and auditors often speak in terms of NIST controls. Abandoning that language increases translation work, especially across MES, ERP, QMS, and OT security tools.
• Traceability: Mapping a unique internal framework back to NIST for audits and customers requires maintaining complex crosswalks.

Tailoring the NIST baseline, rather than replacing it, usually provides a better balance of flexibility and defensibility.

Documentation and evidence for audits

If you remove controls from a NIST baseline, be prepared to show:

• The original baseline you started from.
• Your tailoring decisions, including removed controls and rationales.
• Links to risk assessments, architecture diagrams, and data-flow diagrams supporting non-applicability claims.
• Evidence of compensating controls where you mitigated the risk differently.
• Change history showing when tailoring decisions were revisited after system or process changes.

In a brownfield environment, you may need to collect this evidence across multiple systems (for example, GRC tools, SOP repositories, CMDB, OT asset inventories) and keep it synchronized.

Key takeaway

You can remove controls from a NIST baseline, but only as part of a documented tailoring process with risk justification, approvals, and traceability. In industrial, regulated settings, these decisions must be conservative and well evidenced, given complex system dependencies, long equipment lifecycles, and audit expectations.