This question is undoubtedly very common for many founders and CEOs. A startup typically is challenged with getting the first draft of their product, getting the first paying customer, getting the first investment, and more generally just trying to make it through a volatile market and ever-changing industry climate.
So why should a small company even consider hiring a CISO?
Why should a company divert the already very limited budget they have to a position that is without a doubt not a position that generates revenue but rather consumes precious dollars? Wouldn’t it be more advantageous to invest in another developer? It is a well-known fact that hiring additional developers will result in launching new features earlier, going to market faster (with a better product!), and of course resolving bugs and issues in a more timely manner.
A common approach prior to hiring a CISO is to have the CTO in charge of security, at least officially, and split the tasks and responsibilities between different teams and employees. So the head of R&D will be in charge of the security of the code, HR will be in charge of the physical security and onboarding and offboarding processes, and the finance team will handle all the new service providers in terms of security evaluation — since they’ve already evaluated the aspect of budget for using of new services.
Is this common approach outlined above the optimal approach? Of course not! here’s why:
Let’s first not disregard the fact that it usually takes some time for a new startup to understand that the CISO position is required, it usually happens due to one of two primary drivers – it’s either required by a regulation, or the company is aiming to go up-market.
Its commonplace for the startup to come to this conclusion within the first one and a half to two years after emerging from stealth.
But is that too late?
As a CISO, when I think of a corporate information security I think of several main challenges:
Let’s double click into each of these one by one:
Policies
This is probably the easiest item in the list. I’ve seen so many companies that created and maintained a well-written ISMS, it covered any required policy by most common information security regulations such as ISO 27001 and SOC2, and even included the company logo and the person approving it.
But does it hold water?
Does anyone understand or even follow the policies that have been defined? Sure, there will be cases that the answer for that will be a solid ‘YES!!!’ – but based on my experience, in many cases those policies are forgotten and neglected until a month or so before the annual audit.
Procedures
Much like the policies, every company that respects itself will have well documented procedures, but again much like the policies, there will probably be a significant gap between what is stated that the company does and what is actually done de-facto.
Documentation
This is a soft spot of most companies. Nobody really wants to handle that. Documenting meetings? Documenting incidents? Documenting onboardings/offboardings/position changes? And those are just the “usual suspects”…the list goes on.
Separation of Duties
There’s a chance this is the most important part of a CISO’s job. Why? The product / R&D focus is to reach the target. The target is getting the new feature up, getting the new service provider connected, getting results and getting them as fast as possible. But what about the way that leads to the target? Is the code secured? “Sure!!! We have penetration tests every now and then, so all is good” Well... it’s not.
Penetration tests are just one aspect of securing code. First of all, there will always be a window of potential new vulnerabilities introduced in the product between two adjacent penetration tests, and no matter how narrow this window is, it’s always a risk. Second, a penetration test is not bullet-proof, it’s always limited to the knowledge, experience and abilities of the researcher, it will never cover all possible attack vectors. And of course there’s the question – why wait for the pentest?
Securing a perimeter – whether it’s a physical, logical or code – should be based on circles or layers. Don’t rely on one security circle, add others. For example, review the code, implement a code scanner, add more controls, such as WAF to the environment.
But what is the result of that? More money is required, more time is consumed before introducing new code to the environment; and sometimes the controls will not accept shortcuts and will prevent certain actions or deployments.
If the R&D team is in charge of code security, but their main task is to “get things done,” will they follow the security standards and best practices? A CISO will be in charge of this aspect, and will likely be inclined to meet all the essential best practices. It doesn’t mean that the CISO’s approach will be chosen, but it without a doubt will be always introduced and considered.
Accountability
Sure, it’s not something any company would like to think of, but someone needs to be held accountable in the event of an incident. Who’s accounted for a breach if it is a combination of issues involving different departments?
Guidance
A CISO will be the beacon, the guiding light to get from ‘A’ to ‘B’ in the appropriate way.
Sure, there are 2 types of CISOs The first is the ‘No’ guy. They will always block anything that doesn’t meet the requirements. I do not believe in this approach. Part of the CISO’s job is to say ‘No’ sometimes, but the CISO will need to provide an alternative, to guide the company in the best path from ‘A’ to ‘B’ with as little to no interference to the business.
Considering all of what's been highlighted in this blog, the next logical question is “when is the best time to hire a CISO?” Is it best to hire one only when an Enterprise customer requires it? Is it best to do so only when the company performs their second or third security audit? In my humble opinion I think that’s too late.
I do believe that a full time CISO needs to be hired as soon as possible. It is much easier to set a path, or to introduce policies and procedures while a company is still relatively young, where the threat profile is still quite low, and no significant red flags or bad habits have been established.
And of course, much like any business consideration, when a company’s aim is to meet the requirements in term of business development before they are even raised, it should be the same with the security posture of the company and product – let’s put the right pieces in place before a potential customer demands it that, as its not a matter of ‘if’ its a matter of ‘when.’
This article takes into consideration a very small fraction of the CISO’s responsibilities, and there are many more reasons to hire a CISO, one of the main reasons will probably be the privacy laws and regulations, but that’s for another topic for another blog!
.webp)
.png)
