Compliance on the horizon? Understand your terms now!
I recently worked on a compliance readiness project to get a company ready for an ISO 27002 audit. I was amazed at how little the organization understood about governance. They were having problems with other compliance as well, even though they were a SOX compliance entity. Yes, they had pretty written “policies” but these were clearly designed by the marketing team, had no structure, and included standards, guidelines, procedures, and even documented the people assigned to do it all.
ISACA defines internal controls as the policies, procedures, practices and organizational structures designed to provide reasonable assurance that business objectives will be achieved and undesired events will be prevented or detected and corrected.
ISACA COBIT 5 Framework
Doing it wrong is even worse than not doing it at all!
Poorly-scoped documentation often results in governance functions becoming more of a hindrance than a help. An example of inadequate governance documentation is a multi-page policy document that mixes high-level security concepts, configuration requirements, and work assignments. This type of documentation can cause confusion and inefficiencies across technology, cybersecurity, and privacy operations. There are several reasons why this type of documentation is bad, including the fact that it is confusing and people are unlikely to read it, which defeats the purpose of having it in the first place. Additionally, excessively-wordy documentation that explains concepts in great detail can make it difficult to understand exact requirements. If compliance (or certification) is a goal this can lead to gaps, which goes against the goal of being audit-ready.
Start with the goal in mind
First, start of with the requirements. If the goal is a certification or compliance, your governance should align to the requirements. If you are already compliant with a framework, find a crosswalk, or mapping, from your framework into the desired framework. This can help focus your efforts and help build a plan for what needs to be done.
For many technologists, words matter. Terms like “policies” and “procedures” are often used interchangeably but they are not. These terms have quite different implications and those differences should be kept in mind, since the use of improper terminology has cascading effects.
Also keep in mind that an audit will confirm that policies are being enforced. This means that if a policy says “Bob will update the SSL keys”, what happens if Bob retires? The policy will need to be rewritten! That’s undue work AND it is very likely that it will be forgotten. Another common mistake is to be too specific with tools, such as stating “All servers are to be running Windows Server 2008.” Obviously these policies will not age well. While all policies should be reviewed regularly, little mistakes like these can be overlooked.
Doing it right
In the realm of cybersecurity documentation, a strong governance structure is built on a hierarchy of components that work together in an integrated approach to managing requirements. Keep these components distinct and don’t try to address everything in one document! These components include:
Policy: A high-level statement of management intent that formally establishes requirements to guide decisions and achieve rational outcomes. Policies are enforced by standards and further implemented by procedures, and are often created in response to external influences like statutory, regulatory, or contractual obligations.
Control Objectives: Targets or desired conditions that are designed to ensure policy intent is met. Control objectives help to establish the necessary scope to address a policy and should be directly linked to an industry-recognized practice, such as statutory, regulatory, or contractual requirements.
Standard: Formally-established requirements related to processes, actions, and configurations that are finite and quantifiable. Standards satisfy control objectives and exceptions are never made to policies, only to standards. If a standard cannot be met, a compensating control should be implemented to mitigate risk.
Guidelines: Recommended practices that allow for discretion or leeway in interpretation, implementation, or use. Guidelines are based on industry-recognized practices or cultural norms within an organization and augment standards when discretion is permissible.
Procedure: A formal method of doing something based on a series of actions conducted in a certain order or manner. Procedures are the responsibility of the asset custodian to build and maintain, in support of standards and policies.
Together, these components create a comprehensive and effective governance structure for managing cybersecurity requirements.
For more information on governance and cyber security, check out other articles here.
- The Imperative for Cyber Talent on Corporate Boards - March 29, 2024
- Talking CMMC preparation - March 12, 2024
- Protecting Your Business: Strategies to Combat DNS Attacks - February 20, 2024
