How are security exceptions approved when business systems cannot meet policy?

Security exceptions are controlled deviations from a mandatory security policy. They should be approved only when compliance is not currently feasible, the business justification is legitimate, the residual risk is understood, and an accountable authority formally accepts that risk for a limited period.

The process should begin when a system owner, service owner or security assessor identifies a requirement that cannot be met. Examples include a legacy application that cannot support modern authentication, an endpoint that cannot run a required security agent, or a cloud service whose configuration cannot match an organisational standard. The requester should not treat the exception as permission to bypass security controls informally; it is a governance decision with defined accountability.

A complete request normally includes:

• the policy requirement that cannot be satisfied and the reason for the gap;
• the systems, users, data and business processes affected;
• the operational or commercial consequence of enforcing the policy immediately;
• the threats that could exploit the deviation and the potential business impact;
• the safeguards that will reduce exposure while the exception exists;
• the person responsible for operating and reviewing those safeguards;
• the proposed end date, remediation milestone or condition for withdrawal; and
• evidence supporting the request, such as architecture diagrams, supplier limitations, test results or remediation plans.

Approval should be based on residual risk rather than convenience. The reviewer should consider the sensitivity and importance of the data, internet exposure, identity and access arrangements, exploitability of the weakness, dependency on third parties, monitoring capability and the likely effect of a security incident. A deviation affecting a public-facing system or confidential business data generally requires more scrutiny than one affecting an isolated test environment.

Organisations should define an approval authority in advance. A low-risk exception may be decided by a delegated system or service owner, while a deviation involving regulated information, privileged access, critical operations or a material control failure may need approval from the information security lead, risk committee or business executive responsible for the service. The person requesting the exception should not be the only person deciding whether it is acceptable. Separating the request, technical review and risk acceptance reduces the chance that delivery pressure overrides objective assessment.

The security function or an appropriately skilled reviewer should check whether the stated policy requirement has been interpreted correctly and whether a compliant alternative has been considered. It should also test that the proposed safeguards are practical. For example, increased logging is of limited value if nobody reviews the logs, and restricting access is not an effective measure if broad administrative permissions remain in place. The review should identify any assumptions and state what evidence will demonstrate that the safeguards are operating.

Approval records should use a consistent decision structure. The decision-maker should be able to see the requested deviation, the assessed risk, the relevant safeguards, the accountable owner and the conditions attached to approval. The decision should be recorded as approved, rejected or returned for further information. If approved, the record should state what is permitted and what remains prohibited, so that operational teams do not interpret the exception more broadly than intended.

Time limits are important because a permanent exception can become an undocumented weakness in the control environment. A suitable review point should be linked to a meaningful event, such as an application upgrade, migration, supplier change or completion of a remediation task. Automated reminders, exception registers and management reporting can help prevent approvals from remaining active after their justification has disappeared. Renewal should require fresh evidence rather than occurring automatically.

Some organisations distinguish between standard and urgent exceptions. An urgent request may be necessary to maintain an important business process, but urgency should alter the route and timing of review, not remove accountability. The decision should still identify the risk owner, record the basis for the decision and specify when a fuller assessment will take place. Emergency approval should not become a routine method for avoiding normal governance.

Once an exception is active, its safeguards and conditions should be monitored. Relevant checks may include access reviews, vulnerability findings, endpoint coverage, configuration checks, security event monitoring and progress against the remediation plan. A material change to the system, threat environment, data handled or technical design should trigger reassessment before the stated review date.

An exception should be closed when the system meets the policy requirement, the affected service is retired, the risk is transferred through an approved change, or the business need no longer exists. Closure should include confirmation that temporary permissions, firewall rules, monitoring arrangements and other related measures have been removed or brought into the standard control framework. If the request is refused or expires without remediation, the organisation should follow its risk escalation and change-management procedures rather than allowing the deviation to continue informally.

For cloud and endpoint environments, a central register is particularly useful because one exception can affect several services or device groups. Linking each record to the relevant asset, owner, policy clause, change record and review evidence makes it easier to identify duplicated exceptions, recurring supplier limitations and areas where the security baseline needs improvement.