NIST CSF 2.0: People, Policy and Business Change

As we continue our journey through the NIST Cybersecurity Framework v2.0, we address some of the most challenging elements of governing your Cybersecurity capability: Agreeing who is accountable; implementing security policies; and ensuring adequate oversight and assurance is in place.

Do we have the right people to get the job done?

It’s quite surprising how many people aren’t fortunate enough to have a job description or role definition, but where they do exist, these are often only for the purpose of hiring them into the role they now perform. After which these things can sit in an HR folder and won’t be looked at again.  However, it’s critical to not only define and document all the security roles and responsibilities but ensure that they are well communicated and understood.

One of the additional challenges is to agree who is accountable for cybersecurity, as often the most senior cybersecurity person in the business may not be authorised to take the most difficult decisions, especially those with a significant cost or operational impact. If the person who can make that decision is outside of the security organisation, then they must be in a position which does not conflict with the security objectives.

Part of agreeing the roles and responsibilities is to ensure that you have adequate resources available to manage and run all aspects of cybersecurity. Additionally, achieving management buy-in for cybersecurity is to ensure that all the required roles can be filled. This is often one of the most challenging elements of running a cybersecurity function.

We’ve written a policy; therefore, we must be secure!

Writing a security policy is easy. Effectively implementing, communicating and managing and monitoring a security policy is a lot harder.

Too often are security policies written, sometimes verbatim “copypasta” from an external standard or template, pushed through an arbitrary approval process and then added to a document library. These might make for a nice, polished document to show to a client or auditor, but they don’t represent reality. To start with, policies must define controls based on a risk assessment, which considers both the impact of having a control which is too weak, as well as if a control which is too restrictive. If the business requirements are not considered sufficiently during policy definition, it could impact people’s day-to-day jobs, leading to frustration with security and encouraging users to find shortcuts.

Policies also need to be communicated to everyone they affect, in a manner that they can be fully understood. In many businesses, most users are not technical and therefore this should be communicated in a way that people can absorb, understand and retain. We will discuss effective security awareness in a later blog post

Keeping it fresh when the business changes

Cybersecurity risk management isn’t a one-time activity. Having ensured that the policy is aligned to the business, is implemented and having measured its effectiveness, perhaps you can relax? But only for a minute, as things are always changing.

In the previous post, we discussed the importance of aligning cybersecurity and information risks to Enterprise Risk Management (ERM). Putting cyber risks into a business context and a language which can be understood alongside other business risks is important, however the communication needs to run in both directions.

As well as the ever-evolving threat landscape, introducing new cyber events which might impact your company, the business doesn’t sit still either. Perhaps they want to expand in a new direction, develop a new product or service, or perhaps acquire another company. All these things will impact the cybersecurity risk posture and the security strategy, requiring it to adapt to business changes. Ensuring changes are communicated and their impact evaluated means that any increased risks from business change can be addressed at the earliest opportunity.

Coming up next

Join us next time as we look at the “Identify” function of the NIST CSF and discuss the practical implications of addressing these requirements.

Photo by fauxels