#cso – 370 Security Blog

Are We Peak CISO?

Let’s be honest…the CISO role is weird right now. It is going through a transformative phase and the industry is at an inflection point similar to what other C-Level roles (like the CFO) have gone through in the past. What makes the role weird? The CISO community and any company that has a CISO is facing unprecedented regulatory pressure, the economy and interest rates have people on edge, layoffs in the tech sector have shaken employee confidence (to the applause of investors) and technology innovation via AI is causing additional disruption and risk across all sectors.

In additional to these external pressures the past few years have seen the proliferation of CISO title sprawl and confusion from companies about how to best employ and utilize a CISO (hint, we aren’t your scapegoats). Despite all of this turmoil, change is also a time for opportunity and there are a few things I think will help clarify and mature the CISO role.

CISO Title Sprawl

I’ve been tracking job titles and job postings on LinkedIn for the past year or so and I’ve noticed a phenomenon I’ll call title sprawl. A quick search for titles shows there are vCISOs, Advisory CISOs, Fractional CISOs, CISOs In Residence and Field CISOs. On top of this, add in Chief Security Officers, Chief Trust Officers and Heads of Security. Do we need all of these titles? Maybe, but I think this title sprawl is more indicative of three things 1) People with CISO titles are in high demand and people want to retain the title once they get it and 2) Companies are still uncertain about how to title and employ someone to lead their security function. 3) Title sprawl is a result of the political power struggle occurring between the CISO role and other C-Level roles (more on that below).

From the titles above there are really only four functions for a current or former CISO – board member (in some capacity), executive management (officer of the company), consultant and sales. There is similar title sprawl and variance with CTO titles, but not to the extent of the CISO title (yet). Time will tell if other C-Level roles start to follow suit, but for now, let’s break down the functional CISO role buckets.

Board Member – These are current or former CISOs who sit on a board either as a technical advisor, business advisor or some combination thereof.

Executive Management – Individuals employed by a company to lead the information security program. May also manage other parts of IT such as identity, privacy, data, etc. Titles may be CISO, CSO, CISO in Residence (for Venture Capital), Chief Trust Officer and Head of Security.

Consultant – These are individuals who are providing their expertise as a current or former CISO to other companies to help them establish, transition or manage a security program. Often the companies employing these individuals claim they can’t afford a full time CISO, but they seem to be able to afford other full time C-Suite titles (hmm…)? Titles may include Virtual CISO (vCISO), Fractional CISO, CISO in Residence and Consulting CISO. (CISO in Residence again because they can “consult” to their VC holding companies about the state of their security programs).

Sales – These are people who are experts in the field of security, may hold one or more certifications and may be past CISOs. Their job is to help the company they work for drive sales. Typically the title they use is Field CISO or Advisory CISO.

Standardize The Reporting Structure

Moving on from title sprawl, companies are also confused about where the CISO title should sit. Some companies advertise it as a Director level role reporting into the VP of some function. Other’s title it as a VP level role reporting into a Senior VP or some other executive. Still other companies have the CISO reporting to the CEO, CIO, CTO or General Counsel. It is even possible this person is an individual contributor. Companies are clearly confused about whether the CISO is a technologist, regulatory compliance specialist or true C-Suite executive. While reporting structure may be a direct reflection on company culture, it is also a public example of the battle for equivalency that is playing out between the CISO and other C-Level roles. Often, CISOs are hired by other C-Levels (not the CEO) and until it becomes more common for CISOs to report to the CEO as an accepted peer to other C-Levels, this confusion and variance will persist. That being said, if you are considering a CISO title and the company isn’t willing to add you to the D&O liability policy then you may be better off taking a lower level title to eliminate personal risk.

Bolster Security Management Certifications

Security certifications from popular organizations talk a lot about regulations, risk and different security concepts (technical or not), but few, if any, offer a comprehensive certification on what it truly takes to be a CISO. Any CISO level certification should include potential career paths that lead to the CISO role, career paths post CISO role, difference in the CISO role based on company size, exposure to business topics in addition to security topics, SEC reporting, interfacing with law enforcement and lastly discussion of how to maximize success based on where the role sits – e.g. reporting to the CEO, CTO or CIO and how that may change your lens as a CISO. This begs the question if there should be a true professional level CISO certification similar to a professional engineer, accountant or lawyer, but let’s save that discussion for a future blog post.

Embrace Increased Regulation

Given the recent increase in regulation, particularly from the SEC, bolstering CISO certifications to include more business acumen may soon be table stakes instead of a nice to have. Recent regulations forcing companies to disclose material cybersecurity events in their 8k filings are starting to accelerate the maturity of the CISO role at publicly traded companies. Companies can no longer fail to invest in security or report breaches (unless they want steep penalties). In particular, this is forcing the CISO role into the board room or at least on par with other C-Level roles because they have to help these companies navigate the decision to report material events in their filings. Existing and future CISOs can embrace this increase in regulation to backstop their authority at companies who are struggling to fully embrace the CISO role as a C-Level executive. While it may not elevate the current role with a promotion, it should at least open the door to the board room and provide a seat at the table for discussion.

While CISO reporting structure may be a direct reflection on company culture, it is also a public example of the battle for equivalency that is playing out between the CISO and other C-Level roles.

The last point I’ll make about regulation is – while the SEC watered down the requirements for cybersecurity expertise on boards, I predict this expertise will still be required and in demand as companies start to navigate the new SEC reporting requirements. In particular, companies may be penalized and eventually required to demonstrate cybersecurity board expertise (via experience or certifications) if they are found to have a material security breach and can’t demonstrate appropriate security governance at the board level.

What’s The End Result?

It is clear the security industry and the CISO role are in a state of confusion as a result of the tight job market, uncertain economy, increased regulation and pace of technology innovation. The net effect of title sprawl and the struggle for equivalency is – it confuses customers, investors, partners, recruiters and job candidates. Title sprawl artificially increases competition for jobs and causes a wide variance in how the CISO role is employed. However, I think this state of confusion is a good thing because it is forcing conversations and causing people to stop and think. The CISO role is the newest member of the C-Suite and it is growing up and trading in the hoodie for a collared shirt. We are starting to claim our seat at the board level and are able to hold our own or make other C-Level roles redundant. As the CISO role evolves from a “nice to have” to a “must have” in the C-Suite, we will see this confusion fade away and the CISO role will truly reach its peak.

Defining Your Security Front Door

A key skill for any security program is to partner with and enable the business to be successful. CISOs need to ensure their security teams are approachable, reasonable and most importantly balancing the needs of the business against potential security risks. While security teams exist to help protect the business, they don’t own the business systems or processes and as a result need to adopt an advisory or consultative role with the rest of the business to ensure success.

With that in mind, the way the rest of the business finds and engages with the security team can create a good first impression or can set the tone for a difficult interaction. Think of a house that has great curb appeal – it feels inviting and gives the impression that the owners take good care of their property. The same concept exists for the security program, which I call the Security Front Door.

The Front Door Concept

The security front door defines how the rest of the business engages with and interacts with the security team. The front door can be a confluence page, slack channel with pinned information, or some place that is easily discoverable and accessible. Your security front door should clearly lay out information and resources so the rest of the business can either self serve or easily request and receive help when needed.

What Should Be In Your Front Door?

The front door for your security program should include ways to perform the most commonly requested actions from the security team. For example, you probably want really clear ways to request the following:

Report an incident
Request vulnerability remediation help
Request an exception
Request an architectural review
Dashboards
Discover documentation for policies and processes
Other – a general way to request help for anything else

The front door is not just a way to make a good first impression and enable the business, but when set up correctly it can actually offload the security team and help the business move faster.

Wrapping Up

The front door is a great way to engage with the business to help them move faster, find information and request assistance from the security team. When done correctly it can allow the rest of the business to self serve and can actually offload the security team by reducing the volume of requests that come in. Setting up the security front door may require a lot of up front work, but by understanding the rest of the business, their key pain points and most commonly requested security asks, you can design a front door that will be a win-win for everyone.

Annual Planning For CISOs

The beginning of the year is a popular time for making personal resolutions, which can focus on health, finance or love. While the beginning of the year is a popular time to set resolutions, really what we are talking about is setting goals to improve ourselves. I’m a huge proponent of setting personal goals for the year because it gives focus and purpose to your actions. The beginning of the year is also a great time to review the annual goals of your security program to set your focus and establish priorities. Annual planning has several objectives that CISOs need to consider and include in their process and I’ll cover them in the rest of this post.

Strategic Planning (Strat Planning)

Strategic, or “strat” planning as it is sometimes called, looks at where the business and your organization want to be over a long term time period. Something like 18 months to 5 years is typical in strat planning. The planning session should include discussion of the one or more of the following macro level business topics:

Market forces and opportunities
Industry trends
Regulatory and legal landscape
Competition
Customer sentiment, goals, etc.
Economic and financial environment
Geo-political climate
Technology trends and latest research

This discussion could be part of a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats), but the goal is to understand where your business is and where you want it to go in the long term.

Align The Security Program

Once the business has a strategic plan, the CISO should conduct a similar planning exercise for where they want the security program to be. These are sometimes called “North Stars”, but they are essentially high level objectives over the long term that merge technology trends, regulatory requirements and security goals into long term objective. These won’t be very specific, but instead should act as guidance for where your team should focus and hopefully end up over the next few years.

Examples

An example of a strategic trend and security objective are as follows:

Trend: As companies shift from the datacenter to the cloud and bring your own device (BYOD), the concept of a traditional perimeter no longer makes sense.

Strategic Security Objective: Shift to a zero trust strategy where identity becomes the perimeter.

The goal is to choose big ticket objectives that will take multiple years to achieve, but will provide guidance to your org and the rest of the business about the direction your team is taking. Your strategic plan will inform the next section, which is your operational plan.

Operational Planning (Op Planning)

Operational planning is more tactical in nature and covers a shorter time period than strategic planning. Op planning usually follows either a fiscal or calendar year that way it aligns to performance reviews and budgeting cycles. In op planning the CISO will select the high level goals they want the security organization to complete that year. Usually op planning will include discussion and planning of the following:

Budget creation, forecasting and changes
Headcount planning
Technology investments (if any)
Top risks to focus on
Any audits or compliance certifications needed that year
Development of timing and roadmap for completing specific projects and tasks
Discussion of security controls and services
Skill gaps and training requirements

The point is to create a tactical plan for the year that will inform your team’s specific goals and objectives. These goals should be clear and measurable. I typically use an iterative approach to break my goals down to my directs and then they break their goals down to their teams and so on. This ensures alignment throughout the business.

Measuring and Adjusting

One important aspect of any plan is to continually measure progress and adjust if needed. Goals and objectives aren’t useful if the business has shifted and they are no longer relevant or have become un-obtainable.

Wrapping Up

Strategic and operational planning are important activities for every CISO. These plans define the long term vision for the security organization and break down that vision into tactical objectives that are accomplished throughout the year. This post discussed a high level overview of what goes into strategic and operational planning, but aligning security plans to business risk, mapping security controls, obtaining funding and reporting progress are all complex activities that every CISO needs to master.

Career Options Post CISO

Last year was a busy year for CISOs. Increased regulation from the SEC and other entities are raising the stakes for companies and CISOs. 2023 demonstrated that regulators and law enforcement are not only going to hold companies accountable for incidents and breaches, but they will also pursue accountability against individual CISOs. The CISO role is at an inflection point created by new technologies, increases in regulation and unprecedented personal risk. Given the high stakes of the role I think we are going to see an exodus in the number of people who are willing to shoulder the burden and personal liability of this role. Which begs the question: what are the options for someone after serving in a CISO role?

Serving On A Board

Serving on a board seems like a popular choice lately and now that the SEC has mandated cybersecurity experience on the board I think companies will look to increase their board membership with former CSOs and CISOs. The challenge with serving on a board is finding one that can compensate you sufficiently. I’ve served on several boards over the past 15 years and the compensation will depend on the company size and maturity. Start ups are typically able to offer compensation in the form of equity in the company, but this may turn out to be worthless if the company doesn’t make it. Big company board positions are few and far between, but will pay the best. My advice for CISOs looking to transition into a paying board position is to serve on a board or several boards in your spare time and then transition to become a full time, paid, board member if and when the company can support it.

Advisory CISO / CISO In Residence

One way to “float” between a CISO role and a board member role is to get connected with a Private Equity (PE) or venture Capital (VC) company as an Advisory CISO or CISO In Residence. These roles help the PE and VC companies evaluate potential investments and then help guide the companies to success. If you are an Advisory CISO you can evaluate the companies and if you see one you think has real potential you can choose to be their CISO or serve on their board. Advisory CISOs are not only compensated by the PE / VC company, but they “consult” to the investment companies on a periodic basis and sometimes they are offered the opportunity to invest in the companies they are advising. Not a bad gig.

Consultant

One of the most common post C-Level career paths is to become a consultant. If you are well connected, are in a critical industry or are just great with people, this can be a viable career option. The experience you have built up over your career still has value and companies will pay you handsomely for your time to help advise them. If you work for a company that is unwilling to protect you if you are sued then this may be a way to continue in a CISO capacity, but without the personal risk. I’ve known people who have quit their current role out of frustration and when the company realizes the expertise they are about to lose they hire the person back as a consultant.

Field CISO

Field CISOs are fancy titles for people that are in sales or pre-sales. They typically have a specific region they are assigned and they use the Field CISO title to establish executive relationships with other CISOs and C-Suite members to help sell products and services. Field CISOs typically have extensive industry experience in a particular vertical and then they use that expertise to help tailor solutions to their customers.

Title Change (But Still Security)

Another option post CISO role is to get a title change, but still work in a security related role. This could be something like a Chief Trust Officer or Chief Risk Officer. These roles can offer more flexibility to have a positive impact on the business because they aren’t constrained by the same expectations as a CISO role. At the end of they day you are still a C-Level security executive and can continue to advance your career towards your goals.

Role Change (Not Security)

CISOs are one of the few roles that touch every aspect of the business. As a result, CISOs are well versed in a lot of different business disciplines and it would be easy for a CISO to transition to a CTO, CIO, engineering executive or product executive. For example, a CISO who is looking to exit the role may look to join a security focused startup as their CTO. Their deep industry experience and past credentials will provide credibility and allow them to continue working in the security space in a different capacity. Eventually, they can even hire a CISO to report to them and have oversight over the security function.

Start A Company

CISOs are also well positioned to see gaps in the industry where a solution hasn’t been developed. Lots of well known companies have been formed by former security executives who have left their role to start a company to develop a security related product or service. Starting a company doesn’t mean you have to develop a new technology. You could also start a consulting company, a training company or a staffing company. If you are sitting on a great idea then this is a viable option for you.

Double Down

Lastly, if you enjoy the CISO role, but don’t feel supported or protected by your current company, then find a new CISO role that gives you the support and protection you seek. Part of the interview process for your new role should include questions about who the role reports to, what is the expected budget and headcount, will the role be included in the D&O Policy, what happens if you are personally sued, what is the severance package and how will success be measured? These should all be table stakes for any company looking to hire or retain a CISO and satisfying these requirements will go a long way to making your CISO feel comfortable that you have their back and won’t treat them as a scapegoat.

Chief Incident Scapegoat Officer (CISO)?

Last week the SEC filed a complaint in the Southern District of New York charging SolarWinds and specifically its CISO, Timothy Brown, with fraud. According to the compliant, the SEC alleges the company and Brown made false statements about its security posture to investors. Along with the Uber CISO, Joseph Sullivan, this is the second CISO in the past year to be specifically charged for failing to do their job. In my opinion, these court cases are going to negatively impact the CISO role and make security less transparent to investors. Let’s dive in.

What About The Other C-Levels?

Both cases are unique, however the first thing that stands out to me is only the CISOs are being named and charged. I find this odd because in an ideal organization the CISO still has to partner closely with the other C-Level execs to achieve security objectives. Things like external messaging to customers, SEC filings, etc. all require the coordination and knowledge of other C-Level execs like the CFO, Legal, Marketing and even the CEO. Why aren’t these individuals being named and charged for also contributing to the fraud?

In the worst case scenario, a CISO is poorly supported and struggles to get any of their security objectives funded or implemented. Is the CISO to blame in this scenario? What about the CEO and CFO who withheld funding? How about the Engineering leader who failed to prioritize the security recommendations of the CISO? The point is, I have never found a situation where a CISO is able to operate in a vacuum and so the other C-Level execs also have a responsibility to make sure the company is making true statements and not perpetrating fraud. They should all be held equally accountable.

Responsibility Without Authority

The CISO role has had a lot of press and a surge in visibility over the past few years, but the role still has a long way to go to be on par with other C-Level roles. It is common for the CISO role to report to the CTO, CIO or Chief Legal Counsel. It is uncommon for the CISO role to have a direct reporting line to the CEO. We can discuss who the CISO should report to, but in my opinion, the CISO role still needs to mature compared to the other legacy C-Level roles. The position is currently not on the same level as a CTO or CIO role and this impacts the scope and authority of the role.

Additionally, most CISOs don’t actually own the things they are trying to improve the security posture of. There is always a business or engineering owner that is actually responsible for building and operating the systems that make the company money. As a result, the CISO role typically ends of with all of the responsibility for security, but none of the authority. If the CISO makes a recommendation to fix something and the engineering leader rejects it, who is held accountable for that decision?

Chilling Effect On Open Discussion

My biggest concern with the SEC complaint is the reference to emails that are pointing out the known security issues with the Orion system. Matt Levine wrote a great article in Bloomberg questioning the SEC’s logic and I agree with his assessments. I have never read an SEC filing or investment statement expecting the company to highlight their massive security investments. In fact, I would question if a company should disclose that in a filing at all (unless it is material) because you may inadvertently provide information to attackers that could be used to hack the company.

Additionally, most security teams openly discuss security issues via chat or email. I find these discussions are almost always expressing frustration with current situations with the goal of gaining support for investment to remedy the issue. However, discussions via chat and email also happen to be legally discoverable forms of communication. This means every single email about how much your security sucks will be taken out of context by lawyers and used against you. The obvious solution is to never put your current security failings in writing, which means you can never create a presentation to convince the company to invest in improving security. Or alternatively, if you do place things in writing you frame them in a way that they are asking for legal advice so they can be protected by legal privilege.

Predictions For the CISO Role

I wrote a blog post after the Uber verdict, but both the Uber and SolarWinds cases have caused significant anxiety within the CISO community, which I think will impact the CISO in the following ways going forward:

New CISOs hiring into a role will require companies to list them on their Directors and Officers (D&O) Liability Policy. Also, based on this Bloomberg Law Article about FTX, I recommend making sure the D&O policy specifies how much you will get if all the executives are trying to use the policy at the same time for legal fees.
It will become standard for companies to cover the costs for legal counsel specified by the CISO, should they be individually named in a lawsuit.
As these cases become more common, CISOs will demand higher compensation and protect themselves contractually to minimize their personal risk.
Companies will (hopefully) prioritize security investments to minimize the risk of lawsuits, regulatory actions or security incidents.
Costs for companies to employ and retain a CISO will go up over time.
In extreme cases, the CISO role may shift from a salaried employee to a consultant (I-9) to offload the accountability for security to the company and protect themselves.

Final Thoughts

I can’t recall the last time I saw a CTO or CIO charged with investor fraud for making false statements about their products or enterprise environment. Yet, the CISO role has been getting a lot of scrutiny from regulators recently. I’m all for holding people accountable, but the CISO role doesn’t seem to carry the same weight as the CTO or CIO. The role still struggles with gaining support and funding to place security first. If a company culture is weak or the other executives minimize security, then the CISO will fail to make any meaningful progress. In my opinion, if the CISO of the company is named, then all the officers should be named to drive home the message that they are all accountable for the security of the company.

Exploring The Advantages and Disadvantages of Centralized vs. Decentralized Teams

This blog post is part of the Compliance Corner Series developed in partnership with Milan Patel. This series includes a variety of discussion topics around the intersection of security and compliance. The series includes blog posts, live web streams (with Q&A) and podcasts.

What is more effective – A decentralized or centralized security and compliance team? What are the factors you need to consider, what are the pros and cons of each model, does company size matter, are they simply analogs of organizational maturity or should leaders consider one model over another model for their org?

When leaders are creating or maturing their organization should they consider a centralized or decentralized organization structure?

Lee: If you have the opportunity to create or modify your organization I personally prefer a centralized organization structure. This is because it concentrates the roles, responsibilities and authority for security into a single function that can offer governance and all of the additional expertise expected of a security organization. The rest of the business knows where to go and who to talk to for all security issues. I have seen problems arise in both decentralized and heavily matrixed organizations because it confuses the roles and responsibilities of the function. Who is actually responsible for making security decisions if major parts of security are spread out across the organization? Sharing resources doesn’t really work very well because it is confusing for the individual team members and when sharing resources one side typically loses out to the other side. I have also seen shared resources get mis-used or repurposed for things other than security. This doesn’t mean the security team can’t place resources in different parts of the org, but they should report into and be owned by the security function. In my opinion whoever is responsible for the budget and the headcount truly controls that resource and decentralizing the budget and headcount causes problems.

Milan: Business leaders must first consider what role they want their compliance organizations to have. Will their compliance team actually offer governance, or just auditing? Are they going to cover corporate policies, or just audit frameworks that attest to customer reports? These are important scope questions to answer before setting up (or maturing) a compliance organization. It can drastically change how you fund and scope skills for the team, and whether a decentralized team will meet the overall risk management and corporate goals.

Investment size must also be considered, I get that question all the time, “How much should a business invest in compliance?”. I have seen everyone from flat personnel-project based funding, to actual percent of overall business operations spend. I focus on scope first, as then you can directly cost out what the deliverables/responsibilities are. Governance will drive a big factor of centralized or decentralized teams. Governance requires authority, charter, and appropriate level of independence to actually hold teams accountable. In a decentralized model, governance becomes much more difficult, as the fox ends up guarding the hen house.

Does company size, organizational maturity or other factors influence the decision to have a centralized vs. decentralized organization?

Lee: Company size can definitely influence the initial decision to create a centralized or decentralized function. Smaller organizations or startups may not be able to justify the initial cost of a dedicated security leader and may lump this responsibility under the CIO, CTO or Chief Counsel. As a result the security function may initially grow as a decentralized function until the organization decides it is either time to offload the original leader or they realize they need more specific security leadership and it is time to build out a dedicated function.

Organizational maturity can also impact the decision. Immature organizations may struggle to effectively use decentralized resources and so the weaker the organizational culture the more a centralized security organization will make sense. However, in really large organizations it is common to see a hybrid approach which I like to call a federated model. In a federated model you have a centralized security organization that sets policy, governance, manages risk, makes decisions and has all the authority for anything security. Business units within the large company then staff specific security resources based on expertise for specific industries or to help navigate their specific security and regulatory requirements. This can be advantageous in terms of presenting a single view of overall risk, consolidating processes and leveraging economies of scale for purchases to get a better price for tools or contracts used for security across the organization.

Milan: Company size, and breath of products, can definitely influence the model. In smaller companies, there will likely be less resourcing (and complexity) to consider, which makes a centralized model more affordable and practical. You are not going to have much ability to fund a larger team (and wouldn’t likely need it), so a centralized model pretty much is the only option.

In larger companies, decentralization is used (and we’ll talk about advantages and disadvantages later), but the better model is hub and spoke. A strong central team, chartered with governance, but small “spoke” compliance teams that are the boots on the ground in the team. Small presence that can keep engineering on track, participate in design reviews, threat model reviews, and know enough to ensure that engineering teams and products are on the right track from the start. They also can drive best practices for that team, but they are based on the central team requirements, and can escalate to the central team (that ideally has a governance charter) to ensure adherence at the right senior level.

What are the advantages and disadvantages of each model?

Lee: Centralized models offer consolidation of budget, resources, governance, responsibility and authority. It presents a single function that the rest of the business can go to for anything security related. Centralized models are typically more efficient because it avoids each group having to create and duplicate resourcing, tooling and processes. The one downside of a centralized model is if the security organization forgets that the rest of the business is their customer then it can become extremely difficult to interact with that group who effectively becomes a gatekeeper for business progress.

Decentralized models can offer some initial advantages when companies are extremely small. This is typical during startups or when you are operating in a mode where everyone is doing a lot of different jobs. However, this usually isn’t sustainable long term. I also find people who operate in this mode usually can’t scale to a larger organization where more governance is required. Decentralized models are also more prone to duplication of resources, technology and processes because there isn’t a single leader coordinating strategy and investment. Decentralized functions can also run into problems where the resources are misused or go “native” and stop performing the intended security role. Decentralized functions may end up with different levels of maturity across the different groups in the organization, which can make it difficult to obtain compliance certifications or to standardize processes and technology for a unified approach to security.

Milan: In general, a centralized structure offers the best overall coverage and governance. You can set consistent policies and practices across multiple organizations, which inherently will reduce risk as it’s easier to ensure consistency, and accuracy with one process vs many. You also can provide more controls to validate continuously that processes are working, plus attest much easier. Continuous compliance in a cloud environment is basically the norm now, but not all organizations, especially those with a decentralized model, can effectively ensure compliance of many regulations that come in and now must be enforced at the corporate level, and not just at the product level.

You also reduce cost, as having one set of compliance experts is cheaper, and can provide more optimization of skills. In a decentralized model, you end up having to hire more individuals, as you must replicate specialized skills in multiple areas.

One aspect that is often overlooked in centralized vs decentralized is pricing power. For compliance, for instance, you can collective bargain auditing to drive better prices in a centralized model. In a decentralized model, every team is determining it’s own bidding and metrics, which basically allows for suppliers to cost every team as individuals, reducing the overall negotiating power of the company. In a decentralized model, you usually also have more junior leaders (as the team and overall scope is smaller), and that dilutes the overall governance credibility, as they are not truly objective, as again, this can give the impression of the fox guarding the hen house.

Is there a clear winner here or is this more of a dogmatic approach / “it depends” type of answer?

Lee: Obviously there is always an “it depends” type of answer, but I personally think a centralized team offers far more advantages than a decentralized team. I have operated in decentralized teams, startups, and heavily matrixed organizations and they have all had incredible inefficiencies, process problems, lack of technological standardization and contention between the leaders in control of the different resources. While anyone can demonstrate leadership, the reality is there can only be one leader for a function. If you want to build a strong and effective security organization my personal recommendation is to avoid the decentralized model and strongly advocate for a consolidated, centralized function for all of the reasons I listed above.

No matter what size your company is, at some point your business will get big enough that it will either need to transition to or will need to build a centralized security org. Even when your company gets truly massive a centralized security organization will offer tremendous advantages for coordinating the rest of the functions across the business. This doesn’t mean you can’t have specific expertise embedded within the different lines of business, but there should be one overarching function that sets strategy, governance and has the authority to coordinate everything related to security across the organization.

Milan: I am going to lead off with a “it depends”, but “it depends” on what the SLT wants the function of the Compliance team to be, and how they want them to operate. For example, if they want what they “should” want. Corporate SLT should want an independent compliance organization that has the charter and weight to actually drive governance and accountability. Any decisions made by an engineering leader where the compliance team reports directly to them will be suspect if there is an issue, as how can compliance be seen as impartial if the decision can be overturned by the product or engineering leader directly? Did the right conversation happen, does that decision align with similar decisions with other product groups/lines of business? It can be a real problem if there is an issue and companies have to explain.

That is very difficult in a decentralized model. In a decentralized model where the compliance team, which has to drive hard messages and needs to engineering leaders, are they truly independent and will they speak up, as they tend to be mostly more junior, without any real organizational or peer power with the teams they are supposed to govern? The answer I’ve seen is rarely. I’ve seen and worked with many compliance teams that are frankly afraid to raise issues, or particularly escalate (and if they would escalate, who would they escalate to, as it would be their own management that signs their pay stubs). I’ve seen it both on the compliance and security side, where even mid level leaders will not raise or push issues, as they are worried for their jobs. It’s very difficult to find compliance teams and leaders that can truly be “politically unencumbered” in terms of raising issues, when they report to the fox that likely already doesn’t like having to do compliance work.

I believe that a strong and chartered central team, made up with the right personnel that understand engineering and can translate, and govern engineering compliance practices is the overall best option, particularly for larger organizations where standardization and efficiency must be improved. In a large company, compliance “spokes” with specific charter are important, as it’s the only way to scale the appropriate knowledge down to the teams.

What Causes CISO Burnout?

Burnout isn’t exclusive to the security industry, but it certainly seems like there is a higher incidence of burnout within security and particularly among CISOs. I have had my fair share of burnout and have tried a lot of different techniques to recover, however for this post I want to cover – What are the most common causes of CISO to burnout?

Lack of Appreciation

There are a number of reasons for burnout, but one of the main causes is lack of appreciation. This could be something as simple as celebrating the successes of the security organization more broadly or it can be more complex like advancement to the next level within the company. Given the broad range of CISO levels across the industry, advancement is certainly one of the issues that can manifest as lack of appreciation. For example, I see a lot of head of security positions or CISO level positions posted as Director or Sr. Director level positions. While this may make sense from an organizational standpoint it can put the CISO role at an inherent disadvantage compared to their other peers (like the CTO, CIO, etc.). Celebrating the successes of the CISO, acknowledging their contributions and promoting them to the appropriate level based on their scope and impact is one of the first ways you can reward a CISO, acknowledge their value and prevent burnout.

Lack of C-Suite Support

Another main reason for CISO burnout is the lack of equivalent C-Suite support. If the CISO isn’t supported by their peers and is always at odds with them, this will lead to burnout very quickly. Being on an island all alone is no fun, particularly when dealing with complex issues like security or when attempting to change behaviors across the organization. A CISO needs support and the C-Suite needs to be aligned to the overall security goals of the organization otherwise the rest of the organization will undermine the CISO. Without this support the CISO will spend all of their time just battling for political relevance instead of actually identifying and managing risk and this will lead to burnout.

Too Many Responsibilities

This can vary depending on organization size, but it is not uncommon to see a CISO with additional responsibilities such as Privacy, Data, Risk, Compliance, etc. all in their remit. Typically a CISO does deal with these things, but the organization has to be careful to not lump things under the CISO just because there is no one else to do it. The CISO organization shouldn’t be the janitor or garbage dump for the rest of the org and they shouldn’t be the place where all the misfit toys go. If the organization is going to lump additional responsibilities onto the CISO then those responsibilities need to come with support in terms of additional budget or resources. In addition to responsibilities and resources, the CISO needs to understand their strengths and weaknesses and delegate accordingly. Otherwise, the CISO will take on too much, not be able to scale and burnout.

Operational Burnout

Operational burnout is a big problem. If your operational tempo requires the CISO to constantly deal with incidents, respond to investigations, answer regulatory questions, deal with lawsuits, etc. then the CISO won’t be able to focus on other parts of the job like driving strategy, managing risk or prioritizing resources. Instead, they will constantly be reacting to situations which causes stress and takes a toll on personal health. Operational tempo can be difficult to manage, particularly if the CISO organization is understaffed, which means the team can’t maintain normal working hours. Personal care, such as maintaining normal routines to eat, sleep, exercise and decompress, can be seriously impacted if not managed properly during operational situations and this will lead to burnout extremely quickly.

Another area of operational burnout is constantly dealing with vulnerabilities, keeping up with the the latest trends, dealing technical debt or responding to increased reporting requirements. All of these scenarios have a never ending aspect to them and can cause the CISO to begin to feel like the situation is hopeless.

Risk Tolerance Misalignment

This is a very common area of frustration for CISOs and it boils down to not feeling appreciated. If the CISO is constantly making reasonable recommendations for how to manage risk and the business ignores them then there is clearly a risk tolerance misalignment, which will ultimately make the feel CISO unappreciated. To be clear, I’m not expecting every recommendation to be followed because you don’t want to get into a chicken-little type of scenario, but the CISO needs to have enough organizational credibility that the recommendations are acknowledged, considered and discussed. Organizations that don’t do this will rapidly find their CISO burned out and seeking other opportunities because you can only be ignored so many times before taking the hint and moving on.

Shiny Object Syndrome

At the next conference you go to, take a look around at the vendors and read their messaging. I bet you find it is hard to tell the difference between several of the companies there. Buzzwords like threat intelligence, machine learning, block chain, artificial intelligence, next generation, zero trust, etc. all hype up companies with buzz words, but remove differentiation for decision makers like CISOs. Keeping up with the Gartner Hype Cycle and the latest product buzz words is tiring because CISOs really just want to know what your product does and if it will be useful to solve their problems. Continually having to sift through the noise of buzzwords and hype is exhausting to CISOs and can burn them out quickly to dealing with vendors.

On the other side of this equation is technological churn. If your organization is continually implementing new tools and then replacing them after a short period this can also cause burnout. A security function needs a certain amount of stability and predictability to be effective. Shiny object syndrome from executive leadership or other parts of the business can make it difficult for a security team to find their natural rhythm or implement effective processes around those tools. Shiny object syndrome can quickly burn through the credibility or effectiveness of a CISO, which can ultimately lead to burnout.

Impossible Goals

It takes a considerable amount of effort for a new CISO to make their mark, effect change and achieve their goals at a new organization. This effort alone can cause CISOs to burn out, but it is made worse when the organization has impossible expectations or sets impossible goals for the CISO and their team. Examples of impossible goals are – achieving a compliance certification within an impossible timeframe, improving security posture when there is a significant amount of technical debt or trying to meet expectations for response times without appropriate staffing. The CISO needs to set realistic goals and have the latitude to adjust those goals as needed to avoid burning out.

Lack Of Accountability

The last situation that is sure to cause burnout for a CISO is lack of security accountability in the rest of the organization. If the business expects the CISO function to magically fix all of their security problems without support then that is unrealistic. The business (think CEO) needs to hold the other C-Suite members accountable for supporting and meeting the security objectives set by the CISO. If this accountability is not in place then other parts of the business will keep making decisions that increase risk or incur security technical debt, which places the CISO in an impossible situation and will cause burnout.

Wrapping Up

Burnout is an unfortunate byproduct of an otherwise exciting industry. CISOs are particularly ripe for burnout due to the immaturity of the role with respect to other C-Levels and the wide range of responsibilities that can be lumped under a CISO. Additionally, industry hype, lack of resources, lack of accountability and operational tempos can all cause CISOs to burn out. A CISO who is burned out is not as effective at their role and the level of burnout will take a proportional level of recovery. Hopefully, the examples above can help you recognize common situations to avoid or if you find yourself in that situation, recognize that it will quickly lead to burnout so you can make proactive changes and keep leading your team effectively.

What happens post incident?

One of the most exciting, stressful and true tests of a CSOs ability to lead during crisis is during a security incident. Unfortunately, it is inevitable that CSOs will experience several security incidents during their tenure. This could be something as small as a configuration error, or as large as a full on public data breach. I also think CSOs should assume they are operating in some state of compromise such as a malware infection or an attacker with complete remote access. Given this volatility of enterprise environments and the inevitability of some sort of security incident, the question becomes what happens afterwards? Just because you are no longer under active attack doesn’t mean your work is done. As a CSO, here are some things you should consider after an incident:

Retro / Post Mortem

First, I highly recommend conducting a retro or post mortem on the incident. This is a blameless session to discuss what happened, why it happened and most importantly what the team learned from the incident and what they are collectively going to do differently. During this exercise the CSO should plan to ask questions and listen a lot. I find being the note taker is exceptionally helpful because it is difficult for me to talk while taking notes. I want to hear opinions and ideas from the team on what happened and how we are going to improve. The result of this retro will likely kick of follow on activities such as increased training, requests for investment, development of new processes, creation of new detections or even additional automation. The point is it is a time to learn and rebuild.

Investment

Never let an incident go to waste. Instead of viewing the incident as a failure, I choose to look it as an opportunity for growth. It is easy to point the finger after the fact, but no environment is 100% perfect and secure. Therefore, after the retro is completed it is important to capitalize on the incident to ask for additional investment to respond to the improvement areas raised in the retro. This could mean asking for additional personnel to respond to events, it could mean additional training to fill knowledge gaps, it could mean a new tool or technology to improve detection and response or new processes to improve responses. As the CSO you need to distill down the retro suggestions into an actionable plan that focuses on the risks along with areas for improvement and investment.

Increased Regulatory Requirements

Unfortunately, there are consequences for having a security incident. For publicly traded companies this can come in the form of increased regulatory requirements such as being required to have an independent 3rd party audit your security practice on a periodic basis. It could also mean fines or reporting the incident as material in your upcoming SEC filings. You may even get inquiries from various regulatory bodies asking what happened and what you are doing to prevent it in the future.

Legal Ramifications

Similar to the regulatory requirements your company may face increased legal pressure as a result of the security incident. This could come from a number of different sources such as: lawsuits from outside entities (such as a consumer group or class action), increased contractual obligations from customers who are now concerned about your security practices, law enforcement investigations and costs for outside counsel who have expertise in your specific business area and are helping your company limit the damage.

Financial Implications

This is probably the biggest area for a company to navigate after an incident. Financial implications can manifest in a number of ways. Here are a few:

Increased Cyber Insurance Costs

As a result of the incident, your company may face an increase in cyber insurance premiums. These premiums may even become so expensive that your company can no longer afford to pay them, or your company could be deemed uninsurable.

Customer Impact

Depending on your business, this could be something simple like contracts not getting renewed and loss of new business or it could be something more material like having to pay to notify all of your consumers, paying for credit monitoring and having to compensate your loyal customers in some way to retain their business.

Market Impact

This is a broad area, but post incident your company could face a decrease in stock price. It may even be more difficult for your company to secure lines of credit because of the business risk. The severity and financial impact of the incident could potentially put your company at risk for M&A takeover or may require the business to declare bankruptcy and look for a buyer who has enough capital to weather the storm.

Budget Impact

Again, this is a broad area, but whenever I have an incident I try to keep track of the number of people involved, number of hours it took to deal with it and the opportunity cost of dealing with this versus doing something else I had planned. As an example, the opportunity cost could be something like “as a result of this incident we had to delay project x for 3 months while we dealt with the incident.” All of this will have an impact to timing, budgets and manpower.

Can You Calculate The True Cost Of An Incident?

Unless your company keeps track of everyone’s time and is able to create a time code entry for each specific incident, I find it unlikely that we will ever know the true cost of an incident. There are many direct costs, but there are so many indirect costs that are hard to estimate. The ramifications of an incident may stretch on for years and may change hands from one CSO to the next. However, I do think a CSO should have enough grounding in business principles to be able to estimate the cost of an incident. This can be useful when gaining support from your other C-Suite peers, when presenting to the board or when making investment requests to the CFO. Having context for all of the ramifications of an incident along with potential areas of growth and improvement can be a valuable story to tell.

Compliance Corner Series: Building A Successful Security & Compliance Program

What are the primary factors, considerations, and challenges that a security leader needs to consider to build a successful security and compliance program?

If you were starting a security and compliance program from scratch where would you start?

Lee: I’ve written about starting security programs from scratch in past blog posts, but in my opinion a security leader needs to first select what security controls framework they want to use to inform their strategy, initial assessment and planning. It is rare that a security leader will enter an environment that has zero security and so my suggestion for any leader is to conduct an initial baseline assessment for how well the organization is meeting the security controls within the framework they select. Two of the most popular security control frameworks in the United States are the CIS Top 18 Critical Security Controls and the NIST Cybersecurity Framework. Both of these are excellent frameworks that cover everything a comprehensive security program needs to have along with a recommended prioritized order. It will be difficult for a security leader to start a compliance program without baselining and mapping their environment to a security controls framework because this is the equivalent of never practicing a sport, yet going out and trying to play in a game. Security is the practice and discipline that sets the foundation for successful compliance programs i.e. the sport you are playing. Your security strategy will inform the what skillsets you need to hire, what tooling you need to build or buy and what processes you need to establish to make your security program successful.

Once you have selected a security control framework and have a strategy in place, my recommendation is to then evaluate your business for the markets it addresses, the geographic regions it operates in and the customers or partners it serves. This will inform your compliance team what compliance frameworks and audits they need to consider to make the business successful. For example, if you are a consumer based business and process credit card payments, then you will need to plan to comply with and pass a PCI-DSS audit or if you plan to serve the U.S. Federal Government you may need to achieve some level of FedRAMP. Understanding the business drivers, customer demand and regulatory environment is extremely important to setting up a successful compliance program that enables the business.

Milan: I definitely agree that you must start with a baseline assessment of where you are, but also with what your business goals are. Are you going into financial spaces and require SOC1 Type 2? Do you want to baseline your core expectations with SOC2? What about healthcare, HIPAA anyone? We won’t even get into FedRAMP if you want to sell to government agencies, so I suggest that you need to really understand, and baseline, your business goals in terms of verticals, industries, even governments/regions you want to sell into. The compliance leader will need to balance out these requirements (including privacy, accessibility, etc), to ensure that for whatever region/country/industry you want to go into, you can cover the core baseline controls.

Once you have that, you need a way to track and ensure you can meet those controls. Like we talked about before, and as I talk about now, integrating this with engineering and the appropriate metrics are key. This includes how to “pre-audit” your services for new frameworks/certifications so you can minimize issues during an actual audit. If you don’t do this from the start, retro-fitting it in after the fact is difficult and costly.

You also then need personnel that understand these controls and requirements, and importantly how to translate and negotiate these with engineering. If the people you hire cannot do that, then you fall into the same old challenge of friction between engineering and compliance that introduces risk. Having the right personnel that can translate and bring harmony among the pillars required for compliance (compliance, engineering, security, and operations) will be key to standing up a successful compliance team.

2. What if you inherit a security and compliance program that has been established by your predecessor? What advice do you have for leaders when adopting and continuing a program established by someone else?

Lee: Congratulations if you have been promoted or landed a new role as the leader of a security or compliance program! In my opinion the fundamentals don’t change whether you are starting a program from scratch or inheriting an existing program. I think it is critically important for a leader to baseline and understand what is already in place, what gaps exist and then build their strategic plan to address those gaps. The big difference when you inherit a program is it may take longer for the business to shift priorities towards the new plan due to organizational momentum and budget cycles. Technologically and practically, it may not actually take that long to do the things on your plan, but psychologically the organization will need to adjust and adapt. This means you will need to spend more time building alliances, getting teams on board, changing processes and shifting the culture to support your new vision. Keep in mind that closing the gaps in security control frameworks or compliance activities may take a significant amount of time because the organization may need to procure new tools, hire new talent or create new processes to satisfy a specific control. This has a knock on effect to your compliance program because most compliance audits have both readiness audits and the actual audit themselves. Both of these can take months to complete and so expectations need to be set for timelines, critical paths and when objectives will be met. If the business is expecting to get FedRAMp or HyTrust overnight, that is unrealistic because there are robust processes and timelines that need to be followed to pass those compliance activities.

Milan: I still agree that it doesn’t really change much from standing up a new compliance program, other than you may have a bit more work to change the culture from bad practices to new ones. The key is still to align your compliance strategy with engineering goals/metrics. Inheriting a program that doesn’t align to engineering requires immediate attention, as until you can align it, it will be difficult to help the cultural and behavioral changes needed to more closely align priorities and drive the actual execution.

As you say, it will likely still take time to close gaps, hire individuals, build tooling, but if the actual metrics and success criteria isn’t aligned with what engineering will need to have to actually change priorities, then most of that work may become “wasted” as while it may get you through a single audit, it won’t be efficient or at scale. I would still suggest that new compliance org leaders take a deep look at how the compliance team articulates and aligns success metrics first, before doing anything else, and change/align them to engineering first otherwise they will continue to have friction, and risk, with executing the compliance programs that require engineering (or even operations and security) changes.

3. What challenges can a leader expect to face when building or maturing a security and compliance program and what advice do you have to overcome these challenges?

Lee: There are a few challenges that I have run into over the course of my career. The first challenge is mis-alignment of expectations between stakeholders. This could be a mismatch from the board, from other C-Suite executives or from the rest of the business (like sales). In these cases, it is imperative for the security leader to work closely with these stakeholders to align expectations. You are the expert in this field and you need to help these other leaders and teams understand what good looks like and when they can expect to achieve it.

Expectation mis-alignment is also closely related to cultural mis-alignment. For example, if the technical culture is extremely permissive and allows teams to do whatever they want, then the security leader will need to spend time explaining the advantages of increased security control and how that can actually accelerate the business, while reducing risk. Culture mis-alignment is often the biggest challenge I’ve run into over the course of my career and it can be very time consuming to fix. Security leaders are often brought in to improve a security program, when in reality the culture is at issue. This often means the security team becomes a cultural change agent and they cannot change the culture alone. Security leaders will burn out or leave extremely quickly if the culture is not aligned and they don’t have the support of other executive leaders to achieve the security goals specified in the security strategy.

Finally, one of the other issues I’ve run into is budgetary. This can come in two forms – first, the security team struggles to get appropriate funding and second, the business insists the security or compliance team performs activities that may not actually make sense financially (like achieving a specific compliance audit). The first budgetary issue – not getting appropriate funding can be a real problem for the security team if the business arbitrarily cuts budgets instead of choosing to fund the security team based on risk. This funding issue is closely related to a mismatch of stakeholder expectations and a cultural misalignment. The second budgetary issue is often an issue between sales teams and the security and compliance team. Often, the sales teams insist a specific security control is necessary or a certain compliance framework is required in order to exist in a certain market or achieve a sale. While this can often be the case, it is important the security leader has the support to be able to push back on these requests where it makes sense. If a security and compliance activity is insisted on by the sales team, I always require a minimum threshold of business to cover the cost of the control and compliance activity. This should be written into the sales teams number, tied to their comp and ultimately they should be held accountable for justifying the need.

Milan: I still think the biggest challenge for compliance leaders is building credibility. I talk about how leaders look at all companies as “making money, saving money, or costing money”, and compliance has always been put into “costing money”. So how does a compliance leader build their individual and team credibility with the engineering teams (the main control owners), that they are just not a pain in their collective engineering sides “costing money”?

Compliance leaders must start from the beginning showing engineering how they are “helping them”, which mainly to me is “saving money” (engineering/operations/security time). Time is the key metric that is tracked by most engineering leaders (sprint and engineering time), so it’s incumbent on compliance leaders to show them how they are efficient, or even saving time based on their previous compliance experience. Compliance leaders must be able to show, on paper with metrics, that the compliance work is efficient (I use first time resolution as a critical metric), and how we continuously drive for the ultimate metric, of removing engineering completely from the evidence collection flow via automation, etc.

If you cannot build that trust, then you will always just be a leader that doesn’t understand the engineering priorities, cost them money (i.e. time) by being inefficient, and having no credibility and influence as they have no real reason to engage with you. It all starts with the ability to develop and agree on metrics that actually help engineering minimize the time it takes to do auditing/etc, and providing that value back to the actual engineers.

You get risk mitigation by default with the right metrics, as the evidence is clear and concise, and once first time resolution is high, you can now automate it. We have seen that the risk (and the deviations) have gone way down as we negotiate and approve with external auditors the evidence that will pass that QA for review, we have less “drift” with bad evidence, which reduces overall risk (and actually increases predictability and timeliness in audits).

I also believe that the requirements “accepting” of new frameworks requires a much more detailed review and acceptance than I’ve generally seen. There is no point gaining new certifications if sales doesn’t have a solid plan to get the ROI with customers. It’s costly to go through the certifications, and without appropriate sales to support the cost, it can become wasted work. If the cost/benefit numbers and plans for sales are good, then it becomes much easier to justify the compliance work. Also, if the success metrics and tracking of workload for compliance is also detailed, then justifying resourcing for new projects becomes easier. Compliance teams must continuously run compliance “like a business” being able to show metrics that detail out the work, down to the team and individual level, otherwise justifying new resources becomes challenging.

The Most Powerful Word A CSO Can Say Is No

A Tale Of Two Extremes

A few weeks ago I was sitting across the dinner table from a CIO and a CISO who were discussing how security works within their specific businesses. The CIO was complaining that the security team had unreasonable processes that slowed down his ability to deliver new technology projects within his org and as a result he ignored a lot of their requests. This resulted in an engaging discussion about the best way to balance security requirements against the needs of the business. I found it interesting that some of my fellow CISOs were adamant about having teams meet security requirements without exception, regardless of the impact to the business.

After this discussion I spent some time thinking about own my stance on this issue and how I have tried to balance security requirements against the needs of the business over the course of my career. I pride myself on finding ways to partner with and support the business, instead of just telling them no all the time. However, I have also found that sometimes the most powerful word in my vocabulary is NO. Saying no is particularly useful during the rollout of new processes or security controls where you are changing behavior more than you are implementing a new technology.

Tug Of War

Security requirements and business needs can often be in a perpetual tug of war. This isn’t necessarily a bad thing when you consider the purpose of a CISO organization is to help protect the business not only from attackers, but often from itself. However, it can be difficult when the tug of war is biased towards one side or the other. If the business simply steam rolls and ignores all security requirements then clearly the CISO isn’t valued and the business isn’t interested in managing risk. However, if the CISO says no to everything, then this can be a significant and costly drag on the business in terms of people, processes, technology and time. Lost productivity, lost revenue, inability to deliver a product to market quickly can be difficult to measure, but have real impact to the business. Worse, the business may just ignore you. It is important for CISOs to find an appropriate balance to allowing the business to function, while meeting the desired security objectives to protect it. I firmly believe when done correctly, CISOs can avoid being a drag on the business and can actually enable it.

Just Say No

Despite my general inclination to find ways to keep the business moving forward, I’ve also found saying no to certain things can be extremely useful. For some things, when teams want an exception I usually say no as my initial response. I have found often teams just need to hear an exception isn’t an option and this unblocks them to pursue another alternative to the problem. As a result the teams improve their security while also delivering their business objectives.

Sometimes the teams will ask for an exception a second time. In these cases, I usually reconsider, but often still tell them no. My expectation after telling them no a second time is to either get them to fix the issue or if the issue can’t be fixed to present a plan with different options along with their recommendation. When teams come back for the third time it ends up being an actual business risk discussion instead of an exception discussion. The outcome usually ends up being some sort of compromise on both sides, which is exactly what you want. Taking a balanced approach develops an appropriate level of partnership between security and the rest of the business where one side isn’t always sacrificing their objectives for the other side.

Seriously, Just Say No

Next time a team comes to you with an exception request try saying no and see if they respond differently. You may or may not be surprised when they find an alternate solution that doesn’t require an exception. For me, it has become a powerful tool to nudge teams towards achieving my security goals, while still delivering on their business objectives.