Defining Your Policies and Responsibilities
Policies might not sound glamorous, but they are the foundation of the security management structure in the company. A cybersecurity manager who doesn’t start here is, frankly, likely to fail. Management support and approval for the cybersecurity manager lays the foundation for information security throughout the company.
Identifying Policies
In plain English, the word policy means a rule governing the way something should be handled. In other languages, the word policy can have different meanings, such as the highest level of guidelines or requirements, but generally speaking, people in English-language countries use policy for anything that requires a standard of behaviour—a firewall rule, management intent, and so on. In a cybersecurity context, the word can also mean any technical, detailed setting that has an effect on security. So when we talk about policies in this article, it’s important to understand what level of detail or abstraction we’re talking about. Is it about technical policy for a Windows domain controller setting? Or is it management’s intent on how security should be addressed in the organisation as a whole? Both of those understandings of policy are correct, but they mean different things.
In this article, what we mean when we refer to policy is a written statement, approved by management, on how the organisation or company will react or act in a given area, whether it’s cybersecurity, awareness, or malware. A policy shows the company’s intent and what they strive to do. Policies can be powerful; when management has to sign and approve a policy, they will advocate for it as well.
Policies rarely stand alone; they relate to each other, much like positions in an organisational chart. Policies can be networks or trees of different documents that relate to each other, with branches above and below. The cybersecurity manager might discover a higher-level policy with management statements and a subject-matter policy below that. The cybersecurity manager should understand the control structure well enough to see how they relate to each other and if they make sense in that context.
Larger companies are likely to have policies covering specific parts of their business, such as risk management, business continuity management and HR and privacy. Smaller and midsized corporations might rely on one policy that’s approved by management at the highest level. Or they might have a security manual or common document that compiles all policies in one place. The bigger the company, the more fractured the structure of these documents usually is.
Every policy should have a handful of chapters; the most important topics include the goal and scope of the policy, what is required, and who is responsible. The records must name the person who approved and the date of approval, and may contain version management tables or other bureaucratic details.
Policies vs. Agreements
Policies are not the same as agreements. Policies can be used to direct things inside a company. Policies usually can’t be directly used to influence external parties, for example, the supply chain. Agreements are for that purpose.
Good and Bad Policies
Policies can be right or wrong, helpful or harmful, carefully considered or ill-conceived. The cybersecurity manager needs to know what they are dealing with because an inferior policy can give a bad impression about security. On the other hand, if done properly, policies can boost the security stature of the organisation. Departments usually accept and follow policies that they helped develop and write more than policies that are forced upon them. It’s a good idea for the cybersecurity manager to make a list of existing policies, along with remarks about their quality and acceptance within the organisation. Quite often, the cybersecurity manager is the one who will be maintaining and developing the policies going forward.
To find out what policies are in place, the cybersecurity manager must ask about them. When meeting with management, the cybersecurity manager should ask if there is a policy, if it makes sense, and if people follow it. Four possible answers will follow. First, maybe there is no written policy—it’s ad hoc. Second, perhaps there is a policy, but no one follows it—it’s just a dead paper. Third, the cybersecurity manager might discover there is a policy, and it’s been announced and supported by management, so people know about it. And fourth, even better, the lucky cybersecurity manager might find out there is a policy, it makes sense, and people are following it.
Subscribe To Our Newsletter
Get the latest intelligence and trends in the cyber security industry.
Types of Policies
Cybersecurity managers, who work with technology and systems, will likely work with, and perhaps create, some technical-oriented policies. They also need to be aware of management’s perspective; often the main challenge is to translate the will of management into tech speak. For instance, imagine the director says, “I don’t want anyone weird accessing our information without permission. Make it our policy!” The cybersecurity manager would need to understand that as, “Every user who can access company information needs to have access rights approved by management.” Then the cybersecurity manager must translate the message further to make it implementable. At that level, the policy says that adding new users requires the IT service desk to request authorisation from direct superiors of the employee and that the user needs to reset his or her password on first login.
Many big companies use Active Directory in Windows environments, for example, as user management for the entire organisation. Security settings, policies, and technical policies are controlled centrally from that one centralised system. Since so much depends on it, there might need to be a policy about how to manage security with it.
Similarly, many companies need policies about safely using cloud services. Most companies today are using these services, whether Office 365 or Google Enterprise Services, or another service where everything is stored in the cloud. In the future, they might not own their email servers or their storage space for documents. When that happens, and it has already happened to many companies, they will need a policy about how to safely use those services and to determine what is acceptable and what is not.
Cybersecurity managers might be surprised that policies may also be required for third-party services that aren’t managed by the company, such as social media accounts. Social media might not pose an obvious security issue, but what if employees act recklessly on Facebook? (Just like Mr. Trump is jeopardising America’s reputation with his constant Tweets.) That could cause problems for the company, so almost every organisation now has some sort of social media, or “digital citizenship,” guidelines.
Failure to set up policies leaves the company vulnerable. Let’s say people use weak passwords when they sign up for online accounts, or they reuse their work password and email address outside of work, like at their fitness club or for online shopping. If there is a breach in the third-party service, hackers will have their work username and password. This happens a lot, along with Trump-ish behaviour, making these policies necessary. External services come in two varieties: those that the company supports and tries to get users to adopt and those that users choose without company support. We haven’t found any company that doesn’t have both kinds, and cyber exposure comes from both sources. The company can largely control the first type of service, but the second one is subject to the user’s discretion. It only takes a single user—many businesses have had their information stolen because one user decided to store their information on external file storage and sharing service. When that service was breached, hackers were able to steal the data. It happens a lot.
The company not only needs to make a statement about user-installed third-party services, but a good cybersecurity manager will try to learn what services people are using without consent or support from the company. Furthermore, the cybersecurity manager should strive to monitor any external exposure from all external services, supported or unsupported. Otherwise, they will be in the dark about the related risk.
Identifying external services and products is not always easy because many functions once assumed to be internal are now externalised. In the year 2000, for instance, it was common for every company to have their own server room or data centre. Not so much anymore. More than half of those installations have moved to external service providers or the cloud. Some services are now routinely outsourced to vendors, like IT support, front desk reception, and help desk services. Many companies don’t even own their own laptops any more, but lease them from a supplier instead. All of these services require policies. We predict this trend will continue into the foreseeable future.
Simplicity Is the cybersecurity manager’s Friend
Given how important policies are, it’s understandable that many companies go overboard. We know of a critically important central agency of a government in the Middle East that paid $20 million in consulting fees to create a policy manual and security management structure for the company. In other words, they spent $20 million for paperwork. That’s a big overshoot.
When we came in, they asked us to help solve a problem created by all that paperwork—how to implement all those policies in all their complexity. We were a bit cautious in our first few interviews with them. We told them, “If you want us to help you implement these policies, we will need a copy of each.” We left with a load of documents to read through. When we made a list of them all, it totalled 1,200 pages. (It was detailed enough to include requirements about how to use the door in the server room and which direction every door should open.) 1,200 pages of written policies!
Not Too Much
Policies are internal compliance requirements. Too many of them will create non-compliance very easily!
Having skimmed through the policies, we went back to the security manager of the organisation and asked, “How are you going to make sure everybody in your organisation reads, understands, and acts on 1,200 pages of policies?”
It was impossible. We recommended that they throw away between 75 and 90 percent of those policies and leave only the essentials; they could even condense the key policies down to the bare minimum. After all the money they had spent on the documents, they were not happy to hear this. They expected everything to be done by the time policies were ready. We advised this customer to create an awareness programme that condenses the most crucial 1 percent of those policies to learning materials that are relevant to the daily work of people. The rest of the paperwork was fairly meaningless for the staff at large. Money well spent?
The moral of the story is that every organisation needs to find the right level of detail. Having too many policies will overwhelm the employees who are supposed to follow them, and people will just give up trying to abide by them. The policy only needs to include the necessary details.
When the cybersecurity manager creates policies that dictate things unnecessarily, it will backfire. For example, let’s consider a policy that requires that the system administrator goes through all of the login attempts in the company systems weekly and makes a mark after having done it. Because it’s a written policy, not one review can be missed. An audit will require a log of every one of those reviews having taken place. If one was missed, even if no harm was done, the auditors will then have to make an audit exception and discuss it in management meetings. cybersecurity managers will do themselves a big favour by not creating requirements that may not benefit the company; concentrate on the requirements that matter.
Of course, many policies come from external parties, and there’s no way to avoid addressing them. But if the cybersecurity manager is setting the requirements they themselves have to comply with, it’s often better to use general statements in policies rather than specify too much detail into the requirements.
Save the specifics for where they’re needed most—areas of real risk. Each policy should be based on some real risk or threat. If there’s no real risk or compliance requirements, there’s usually no need to implement a policy governing it.
A Policy by Any Other Name?
Policies, procedures, guidelines, and standards—What do they all mean?
Not everybody agrees. A lot of companies label things as policies that are actually procedures. Procedures describe the steps necessary to do one process or task. The term should be used when the content is practical. They describe detailed security process steps that must be taken. Quite often, procedures state mandatory things that need to be done.
A guideline, on the other hand, is usually something that should be done. It’s more of a lightweight obligation. For instance, the company might make a social media guideline that contains 200 pages of good practices on how to live an ethical life on social media, but it’s not mandatory that all employees follow it. They probably should, and if they don’t, they may get called out on it, but ignoring a guideline isn’t a firing offence, whereas a policy or procedure oversight might be.
Finally, companies, industries, and government bodies also set standards—a unified set of requirements for all instances. For example, ISO27001, part of the ISO/IEC 27000 series of cybersecurity standards, is a standard of good practice for information security that contains requirements that generally apply to all kinds of companies. Though all companies are different, the set of requirements are the same. By the same token, a company might have an internal standard for configuring Windows servers. All of the technical settings could be dictated in the internal standard.
