Why Context is King for Your Governance Program

Security is a process. It takes time to build a strong security posture within an organization and commitment to optimize and manage it. Governance is implemented as a means by which organizations can control the security management and direct their approach.  A well-executed governance program is meant to effectively coordinate security with business operations and allow for a safe flow of information around your organization. It must be able to leverage risk management, security policies, and strategies pertaining to the particular security and business needs of an organization. But does your security governance always work for the company’s best interest?

Founder and CEO of VerSprite Evolved Security Consulting Tony UcedaVelez discusses the underlying problem of security governance and the usage of policy frameworks.

Governance is essential to any security program. Policies lay a foundation of beliefs for a company that should be obtainable, while still support a high degree of the company’s ability to maintain effective security controls. Security policies provide a base layer to this governance program. These policies should reflect the unique capabilities, controls, and processes of the organization, among a slew of other variables that make up a more contextual approach to policy buildout.

Something too overarching will make security implementation unobtainable, perhaps triggering an avalanche of workflow of exceptions. Something too lax may coddle the organization and undermine adequate security controls that are needed to be more robust.

Context is KING here and it will vary per organization. In policy buildouts, it is forgotten nearly every time and put in the backseat to simply instantiating security policies that could be shown to auditors. So many consulting firms and enterprises leverage policy templates as the start AND end to building security policies. We all have seen them – {insert a framework} inspired templates du jour catalyzing the drudgery of policy development for the purposes of placating auditors with their endless demands.

One thing to consider is that policies can often serve as the initial step for a CISO to foster a security culture across a given enterprise. A set of policies solely inspired by a framework – of which knows nothing on the business runs, what represents the tech stack, if and how an outsourcing model is present, or what inherent threats affect the overall business model is like taking a gym workout plan and applying it to anyone without understanding body type, preexisting health concerns, goals, or prior fitness knowledge.

Build custom. Develop security governance that will not only protect your assets, but will work for your business continuity. Keep in mind also that policies are very fluid. They get modified, expand and can contract in number, scope, and even relevance (Clean Desk Policy, as an example).

There is nothing wrong with ensuring that policies can align to a reputable framework – that is not the point here. It is, instead, that policies must be first built considering more contextual variables that pertain to the enterprise vs. simply copying down what a group-produced framework says about a business it never knew.