Create a Cybersecurity Development Plan
As soon as the cybersecurity manager has a firm understanding of the structure of the company and the current security liabilities, the next step is to create an effective cybersecurity development plan. This plan will provide a blueprint of actions to help them move forward in securing the company’s data. This planning stage is when the cybersecurity manager starts to map out what should be done in the next year to eighteen months.
The recommendations that go into the cybersecurity development plan are based on the real risks uncovered by talking to the stakeholders and leaders at the company. That may be a long list, so an important function of the cybersecurity development plan is to prioritise to-do items. For example, after talking to the stakeholders, the cybersecurity manager might learn that there are actually two glaring vulnerabilities that have to be rectified immediately based on business needs. Those would go at the top of the list.
In a good case, the requirements will be both compliance- and risk-based. Hence, they make total sense to the company management and also tackle compliance problems. It’s a win-win. A risk-based decision might be as simple as purchasing a burglar alarm system. Perhaps the company doesn’t have a burglar alarm system in place, yet they’re located in an area with a high risk of burglary. Even if buying an alarm system costs tens of thousands of dollars, it could be a smart decision to minimise risk.
Compliance-based items will probably revolve around regulations or standards. Perhaps the business is required to have a business continuity plan and incident response plan in place. For a smaller business, these types of plans usually don’t make much sense, so most small companies don’t have them. But if it is mandated by a regulation, the small business will have to spend money on creating those plans just to be in compliance, even though management may feel it’s unnecessary.
The challenging thing about compliance is that you have to cover every part of the standard set forth in the regulations, one item at a time, until you’re done. For most items that are not completed, the cybersecurity manager must mark them as to-dos and then find the most cost-effective way to accomplish them. That often creates another long list of things-to-do items for the cybersecurity manager.
In other circumstances, compliance items can be marked as not applicable. It’s a grave mistake to try to meet every single requirement as-is. The cybersecurity manager should investigate whether some requirements actually pose any significant risk or not. Under some compliance schemes, it’s quite possible to not implement requirements if there’s no accompanying risk whatsoever. This is one kind of outscoping tactic that professionals use to reduce their scope of requirements.
Colour-Coded Progress
Creating a cybersecurity development plan isn’t necessarily complicated, though. It could be as simple as making a list of prioritised and scheduled tasks in an Excel spreadsheet. To keep it simple, the cybersecurity manager can take a Payment Card Industry Data Security Standard (PCI DSS) or an ISO-27001 standard and copy and paste all the headers into Excel. Then under each header, enter some subtitles for each of the requirements. That would be an easy way to get started.
Subscribe To Our Newsletter
Get the latest intelligence and trends in the cyber security industry.
Making a List
Auditors may assume applicability of all requirements, but you can show them the exceptions. Simply create an Excel spreadsheet and list the requirements. Next to each requirement, specify the reasons there is no risk involved.
For example, if the requirement calls for securing the loading bay and you don’t have one, you can reasonably opt out.
Give this list to the auditor, so they have something to walk away with.
If the cybersecurity manager must do something on that list, that’s considered a mandatory item and would be a top priority. We suggest marking whether each task is accomplished or not using the green, yellow, and red highlighting system in Excel. Once you’re finished colour-coding this to-do list, it will become a large spreadsheet full of green and red markings denoting items that are either done or not done, or not applicable, if the items can be outscoped.
Every task that’s marked as done requires evidence to prove that it’s been completed. This means you need written, documentary proof. If you have a security control in place, but you have no documentary evidence to prove it, then you’re not compliant until such evidence can be presented either in writing or by means of observing. It is customary for auditors to first look for documentation. Most often, they will be satisfied with written evidence. If there’s no such evidence, they might opt to observe how the requirement is met or not. That is slower, though. Many to-do items can be brought into compliance simply by writing a short explanation about how you met a certain requirement and where the evidence is. The written documentation doesn’t have to be exhaustive; not everything needs to be on paper.
Working with Auditors
When you’ve made a checklist of all the requirements, you have a chance to prepare for the auditor’s visit. You can also help the auditor by providing those materials ahead of time.
Set the tone for what can be long sessions with the auditor by reserving a comfortable meeting space. Make him or her feel welcome, and provide some refreshments.
At the meeting, lead by explaining the weaknesses you’ve already identified and explain how they will be fixed. The auditor wants to find these weaknesses, so point them out.
Sometimes, handing over that list of fixable items is sufficient. The auditor walks away happy. If not, they may dig deeper, which is not a problem because you’ve come to the meeting totally prepared.
After going through this list, anything that remains unfinished despite your best efforts will become your ongoing to-do list. These will be the items you focus on over the next twelve to eighteen months. After this list is prepared and updated, the next thing to establish is your time schedule and who is responsible for which tasks.
Each of the requirements on the list needs to have a person’s name attached to it and needs to be discussed with the person it’s assigned to. They’re not going to do it if they don’t know that they have to. This requires many meetings and a lot of discussion and presentations; it can take a long time to achieve. Usually the cause for delays is not the amount of work to be done but the amount of communication and the number of meetings required.
For instance, if the plan calls for installing antivirus software on the Windows servers, the cybersecurity manager is probably not the person to do that. That’s the IT team’s domain. The cybersecurity manager should not be the one buying the licences, installing them on the servers, checking that everything works, and troubleshooting as needed. The cybersecurity manager should talk with the head of IT and let them know there are requirements that need to be met and then let the IT department do it.
How fast a cybersecurity manager can accomplish the items on the to-do list and reach compliance largely depends on how fast they can schedule the required meetings and how well they communicate with the people involved, motivate them, and get them started. It usually takes months because just getting a meeting scheduled with any busy business person can take weeks. So the cybersecurity manager should always be realistic about timeframes.
Once the cybersecurity manager is making progress accomplishing to-do list items, it’s time to look at the bigger picture of security at the company. Now the cybersecurity manager should think about long-term strategic planning; it’s an opportunity to design an effective security organisation within the company and to figure out what long-term budgeting is needed. Do you need a team of specialists working for you? Do you want to apply for a budget to hire some people for new security roles? Hiring permanent positions might be necessary in a bigger company.
Planning Pitfalls
There are a couple of common pitfalls cybersecurity managers face when creating a plan for short- to medium-term like the twelve-to-eighteen-month plan we’ve been talking about. First, too many cybersecurity managers use compliance standards as a plan or as the basis for a plan. The potential pitfall here is that the bulk of the cybersecurity manager’s time will be directed toward achieving compliance status, instead of working on actual security improvements. If the cybersecurity manager decides that they need to do proceed from a compliance standpoint, they’re going to spend a lot of time looking at the specific requirements to make sure they are met, when, in reality, they can probably comply with most of the requirements just by collecting existing evidence and documentation without actually doing much new security work.
Ironically, a compliance-based plan can actually backfire. If management sees that the cybersecurity manager doesn’t appear to have any to-do items left on her list, they may pull funding of the cybersecurity manager position. In other words, doing just compliance will get the cybersecurity manager into trouble. Compliance must be part of the cybersecurity development plan, but the cybersecurity manager should not focus solely on compliance.
Starting with a purely risk-based approach can get the cybersecurity manager in trouble too. It might not come back to bite the cybersecurity manager immediately, but sooner or later the compliance items have to be covered; they cannot be ignored. Every company in a given industry has to do the same things, and other companies will not be happy if their competitor seeks an advantage by not complying with industry regulations. They’ll think the company is playing dirty, and they will complain. Then regulators will respond by taking away the company’s licence to operate in that market.
If a company has been doing good work with security management based on risks, it will not mean they are compliant. They might be relatively secure but still not meet the mandatory requirements. Being secure but not compliant means the customers may be well protected, but there can be no reliance on this! It means that the company can’t put “secured by” kind of logos on their customer pages, they can’t use it in their marketing, and they will be asked about it often. They will see more auditors visiting due to non-compliance. it becomes a validation problem of sorts. Compliance often leads to certification, which is one type of external independent validation. This helps third-party stakeholders like customers to quickly deduce whether the company can be trusted or not. If they have a “secured by” logo, then why not buy online?
Neither risk nor compliance can be ignored.
