Your written security policies for your business were created at a particular point in time, for a particular set of circumstances. But circumstances change: this is why a regular review of your security policies is a good idea, to check that they are still appropriate.
So: circumstances changed. Now you need to do something (X) for business reasons, but the policy says that X can’t be done. And rewriting the policy to allow you to do X is inadvisable for some specific reason. Perhaps X-type things are particularly risky, but the business has decided that this specific X is important enough to accept the risk in this case only.
There may be a case for a temporary exception to the policy.
Why might you need a security exception?
A security exception is not a work-around just to make life easier for someone. It should be a rarity: perhaps a reaction to a short-term change in the way your business operates, or forced upon you by an external requirement.
Example 1
The policy says that you will apply patches for vulnerabilities within a certain time. You have just received notification of a vulnerability. However, for one system within your environment, applying the patch is a higher risk than not applying it. Maybe that system is fragile and likely to be badly impacted by the patch. Perhaps it is end-of-life and you plan to replace it soon after the prescribed patching period. In this case, an exception could be requested until the vulnerable system is replaced with a newer version, and additional protective measures put in place.
Example 2
Your business acquired another business, which operates under a different set of policies. Until the integration of the two is complete, an exception is needed to allow them to operate under their original security policies.
Note that in both these examples, the need for the exception is time-limited.
Example 3
You want to work with a particular supplier that does not have an accreditation that your policy requires; and there isn’t an appropriate alternate who does. In this case you might make an exception on the basis of business need, and consider time-limitation by requiring that the vendor work towards accreditation within a suitable time-scale, or time-limiting the contract with them.
Controlling security exceptions
Security exceptions should be carefully considered and controlled. At some point, a policy with many exceptions is no longer working as a policy at all.
You may not yet have a process for managing or even defining security exceptions. Here are some considerations:
- Clearly define and time-limit each exception request
- Document the request in detail, with justification
- Identify any new security controls needed to minimise the additional risk caused by the exception
- Consider the exception alongside any other pre-existing ones, because there may be a cumulative risk to the business
- If you decide to authorise the exception, check that you have implemented any additional mitigating controls
- Review the list of exceptions regularly
- If you still need the exception after the agreed time period, or if there are repeat requests for the same exception, then review the policy.
Want some help with this, or with writing any other security policies? Contact the Click and Protect team on 0113 733 6230 or use our web form. We’ll get back to you as quickly as possible.
