A good information security policy should very clearly state a number of things. At least the following:
- The reason why it was implemented
- its goals
- its scope
- its boundaries (the things it does not apply to)
- clear requirements towards the assets that are part of the scope
- controls that meet these requirements
- responsibilities
There are (at least) two kinds of policies that are self-written. The ones that set organizational rules and the ones that set technical rules. The latter are sometimes called 'standard' or 'guideline', for instance 'Guideline for configuring Windows Server 2012'. If you are the person that is giving names, try to give the same name for the policies with the same scope.
A very small policy that sets organizational rules could look like this.
- Employees noticed that visitors tend to stare at their screens
- To reduce screen staring this policy will be implemented
- This policy applies to employees of level 1
- It does not apply to employees of level 2 and 3
- & 6 All employees are required to lock their screens if they have a visitor in their office. If the visitor needs to look at the screen, because of business reasons, employees have to make sure, that the visitor is only able to see what she needs to see. This can mean to close all other windows, even if this harms productivity while the visitor is there.
7 managers are required to monitor this behavior on a sample basis.
How can you measure compliance with policies that set organizational rules?
You can't really. (and also auditing)
You can ask employees if they comply with the policy. On the one hand this is risky, because your employees will often times answer as they think is socially expected and so will their managers. On the other hand if the process of asking is thorough, this can yield good results. If your employees do not necessarily have to fear backlash if they don't comply with a policy, they will be more honest. A nice side-effect: can also ask them why they don't follow the given rules. There is often a discrepancy between how processes are planned and built - and how they are "lived".
You could test employees with regards to what they know about a policy and its details. But then you will only know if they know about the policy, not if they enforce the rules that are set there.
Because of these problems some organizations do the following: when it comes to policies that set organizational rules.
- implement policy
- employees have to sign statements that they will comply with policies that are published companywide and that apply to them
- publish policies companywide and/or to the respective groups
How can you measure compliance with policies that set technical rules?
Auditing.
The best way to do this, is auditing. There are all kinds of audits with all kinds of different scopes. If you want to measure if your controls are effective (= meet the requirements) and if they have been implemented correctly you should hire an auditor or look up auditing techniques. I would recommend hiring because 1) audits are tedious and 2) having an outside perspective can be very helpful to find flaws in processes and controls.
Get to the point! How do auditors measure compliance?
Well... there are different techniques which really depend on what you want to measure.
There is the basic: X machines of Y, so Z% have vulnerability with a CVSS score of 7 or higher. - You'd measure compliance with a policy that sets rules with regular vulnerability scans.
Compliance will most of the time come down to "yes/no/partly". The rules that have been set in a policy could look like the ones you can see here.
For instance:
"The auditor should verify that management has controls in place over the data encryption management process. Access to keys should require dual control, keys should be composed of two separate components and should be maintained on a computer that is not accessible to programmers or outside users. Furthermore, management should attest that encryption policies ensure data protection at the desired level and verify that the cost of encrypting the data does not exceed the value of the information itself. All data that is required to be maintained for an extensive amount of time should be encrypted and transported to a remote location. [...]"
These can be very easily measured with interviews of experts and technical audits. For instance: what TLS version is in use, how is back-up data encrypted, etc.
There are also more complex goals that can be set up before an audit but these are probably not what you are looking for, because they require complex processes and controls to audit. These things are normally not set up via policies.
In the end it comes down to the auditor and the technique she chooses. If you hire someone, arrange this beforehand.
If you don't choose to audit you will have to define how much risk is reduced after a policy has been implemented and: 1) employees don't know about the policy, 2) employees always comply with the policy and all the varying degrees between these two.
