How should organisations structure IT GRC requirements when moving from classic baseline protection to a must, should, can model?

Why This Matters for Security Teams

Moving from classic baseline protection to a must, should, can model is not a formatting exercise. It changes how IT GRC teams prove intent, show risk acceptance, and defend scope during audits. A baseline list often implies every control is equally required, which creates noise and hides the controls that actually reduce exposure. A tiered model makes ownership clearer, but only if each requirement is tied to a business risk, a technical dependency, or a compliance driver.

This matters especially where identity, secrets, and service-to-service access are involved. NHIs are often overprivileged, poorly inventoried, and missed in periodic reviews, which makes requirement clarity essential. NHI Mgmt Group notes that Only 5.7% of organisations have full visibility into their service accounts, a useful reminder that control language must be operationally testable, not aspirational. Aligning tiers to NIST Cybersecurity Framework 2.0 also helps when translating broad governance goals into enforceable requirements.

In practice, many security teams encounter control sprawl only after audit evidence becomes inconsistent and remediation work has already been delayed.

How It Works in Practice

A practical must, should, can model starts by rewriting requirements into three distinct obligation levels. Must covers non-negotiable controls that are required by law, contract, or core risk posture. Should covers controls that are strongly recommended because they materially reduce risk but may be deferred with documented justification. Can covers optional enhancements, maturity targets, or environment-specific improvements.

The key is to tie each control to an explicit rationale and evidence standard. In GRC terms, that means recording why the control exists, who owns it, when it applies, and what proves it is operating effectively. This is where control families from NIST SP 800-53 Rev 5 Security and Privacy Controls and ISO/IEC 27002:2022 Information Security Controls can be translated into enterprise language without losing traceability.

For example, a must requirement might mandate secret rotation for production service accounts, while a should requirement might call for automated detection of unused credentials, and a can requirement might suggest stronger anomaly analytics for high-value systems. That hierarchy helps auditors see the difference between required control performance and optional maturity uplift. It also helps control owners avoid arguing about every item as if it were equally critical.

• Use must for regulatory, contractual, and high-impact security obligations.
• Use should for controls with clear risk reduction but some implementation flexibility.
• Use can for enhancements that improve resilience, observability, or efficiency.
• Attach a test method to every requirement so evidence collection is consistent.

For identity-heavy environments, this structure is especially useful when mapping service accounts, API keys, and privileged automation into separate control tiers. The Schneider Electric credentials breach is a useful reminder that weak handling of secrets and access paths can turn a “recommended” control into a real incident.

These controls tend to break down when requirement owners mix policy intent with implementation guidance, because teams cannot tell what is mandatory versus merely preferred.

Common Variations and Edge Cases

Tighter requirement tiers often increase governance overhead, requiring organisations to balance clarity against administrative load. That tradeoff becomes visible when business units want local exceptions or when control libraries were originally written as single-level statements. Best practice is evolving, but there is no universal standard for whether should and can tiers must be risk-ranked numerically or qualitatively.

One common edge case is inherited controls from frameworks that do not map cleanly into a three-tier model. In those cases, the safer approach is to preserve the original control reference and add a policy interpretation layer rather than rewriting the source obligation. Another edge case is cloud and platform engineering, where some controls are must at the platform layer but should at the application layer because the technical ownership differs.

It also helps to distinguish between requirement tier and implementation method. A must requirement can still allow multiple acceptable ways to meet it, while a can item may become mandatory in a regulated business line. For organisations building from NHI-heavy operations, this distinction is particularly important because service-account hygiene, secret lifecycle, and access review logic often span infrastructure, app teams, and security operations. NHI Mgmt Group’s Ultimate Guide to NHIs is a strong reference point for translating those recurring NHI risk themes into auditable control language.

In practice, the model works best when exceptions are time-bound, evidence-backed, and reviewed at the same cadence as the risk register.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on opaque business applications for access control and data protection?
• How should organisations plan for GRC control continuity when Oracle GRC support is ending?
• What breaks when organisations keep using end-of-support GRC software without a transition plan?
• How do organisations operationalise NHI ownership at scale?