It is with some surprise (and frankly, confusion) that I now realise not all security professionals think information security policies (ISPs) should [must!] be aspirational in nature.

By ‘aspirational’, I mean that at least some aspects of your ISPs require a greater degree of control / implementation / assurance etc. than you are currently capable of achieving in reality.

The ‘accurate policy’ proponents feel that if the policies do not reflect exactly what you are doing, then what you are doing is in violation of your own policies, thereby effectively rendering those policies useless. I assume, by extension, that they consider compliance with any regulatory regime is also nullified.

Here’s an example of what I mean by an ‘accurate’ policy statement:

The Access Control policy would include something like;

“All company systems capable of enforcement of strong authentication will implement it.”.

…but an ‘aspirational‘ Access Control policy would state categorically that;

“All company systems will implement strong authentication.“

Now, what if a legacy system is incapable of strong authentication (as defined in an Authentication standard identical for both policies above)? What happens?

Because the intent of the ‘accurate’ policy has been met, no further action is required. As a result, a system that cannot support appropriate security will be under no further consideration from a policy perspective.

However, in an ‘aspirational’ scenario, the owner of the non-compliant system will have to do some or all of the following depending on the level of risk.

1. Apply for one of the following (terminology may vary):
   • Policy Exception – the system will never be capable of achieving the desired policy standard, so an exception is needed for its entire life cycle; or
   • Policy Variance – the system is capable of achieving the desired policy standard, but time is required to get it there;
     o
2. Run a Risk Assessment (and possibly a Data Protection Impact Assessment (DPIA) as well) to let management know what risk(s) they are signing up to – they will then have several risk treatment choices:
   • Avoid – get rid of the system all together;
   • Reduce – mitigate as much as possible;
   • Transfer – outsource the device’s function;
   • Share – insurance etc.;
   • Accept – accept the risk as is with no mitigating action.
     o
     

     The only thing management can’t do is nothing, as even risk acceptance involves management signing off on the residual risk;o

3. If a variance is approved, and any treatment other than ‘Accept’ is chosen, system owner must now develop a Risk Treatment Project Plan to include an estimated date for completion;
   o
4. Add approved exception/variance to the corporate Risk Register to track resolution (through the Governance Committee or equivalent program management function);
   o
5. Implement the risk treatment plan.

No ISP is complete without an exception/variance process, so no system should ever be outside of an approved policy umbrella.

Aspirational policies in conjunction with a comprehensive risk register is one of the most effective ways to not only ensure that the concept of continuous improvement becomes intrinsic to the culture, but that stuff gets fixed.

Clearly there is another side to this, one that given my obvious bias I am in no position to explain or defend, so I would happily post a guest blog as a rebuttal.

Who’s up for writing one?

It would also be great to hear your thoughts on the matter, see if we can’t come to a majority consensus.

[If you liked this article, please share! Want more like it, subscribe!]