Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
Deciding how to organize an information security team and determining its resources are two threshold questions all organizations should address. This piece provides guidance from our Faculty on how to do both and explores the nuances that influence those decisions.
To right-size and structure your information security organization, you should consider:
Here are some key methods organizations can use to help determine information security risks:
Use a risk register to capture and manage information security risks.
Base the risk register on executive input. The process for populating the risk register should start with documenting executives’ key worries concerning the CIA of data. Note the emphasis on “worries” vs. “risks.” You are
not seeking to find out what “risks” concern them; you just want to know their “worries.” This is analogous to a doctor asking a patient where it hurts, how bad the pain is and whether the pain is persistent or intermittent.
The doctor does not expect the patient to determine what the disease is – just the nature and location of the pain.
Ensure risks can be traced back to leadership priorities. Once the “worries” are captured, the security team can convert them into information security risks. But the key is to have traceability between “risks” and “worries,”
so when you talk about risks to the executives, you can relate them back to what they told you they were worried about.
Position the team and its resources to address the worst risks. Once all of the risks are documented and prioritized by severity, you should be in a position to ensure the security team’s organization and resources are suited to addressing the worst
risks (lesser risks typically are just monitored and only get addressed if they get worse). This is a key point: If the information security team focuses on the worst risks, its organizational structure should reflect that focus. Organizational structure
(or resource allocations) can change as the risks change over time.
The following is a list of information security responsibilities. Important to note, not every security team must perform all of these, however, decision should be made – by team leadership and company executives – about which should be done,
and which may be ignored or handled by other groups. Once it is determined which responsibilities will be handled by the information security team, you are able to design an organizational structure and determine resourcing needs, considering the
risk register’s worst risks:
Whether infosec is responsible for some or all these functional areas depends on many factors, including organizational culture, geographic dispersal, centralized vs. decentralized operations, and so on.
The above list covers functional areas, but there are, of course, tools within each area that may or may not be funded as security spending (vs. just routine IT spending). Generally, if a tool’s principal purpose is security, it should be considered
as security spending. If the tool’s purpose covers a variety of needs, from security to business management (such as many IAM tools), then it should be considered IT spending, not security spending.
Security operations can be part of infosec, but it can also be considered part of the IT infrastructure or network group. It's not uncommon for IT infrastructure and network groups not wanting anyone besides themselves touching the devices that manage
their network (including firewalls, routers, load balancers, etc.). The potential for errors and miscommunication (and outages) can be great.
If security operations is part of IT, whether it is insourced or outsourced, is usually a function of how much IT is insourced or outsourced. If network management is generally outsourced to a managed services provider (MSP), then security operations
usually is too – to the same MSP or to a separate managed security services provider (MSSP).
Generally, smaller companies use a lot of MSP or MSSP resources, while larger companies do more in-house and only call on external resources for specialized functions and roles. Companies that use a lot of cloud resources may employ a CASB to help manage
access to cloud resources – again, an outsourced function.
Although one size does not fit all, the infosec team's typically follow a structure similar to the following:
Figure 1 provides a responsible-accountable-consulted-informed (RACI) chart for those four primary security groups, plus a privacy group. Wherever a security group is accountable for something, it means the group is accountable for the infosec oversight
and governance of that something, not necessarily operational execution. For example, the infrastructure security team is “accountable” for server patching, so it oversees the security aspects of the patching process (e.g., setting rules
for patch priority, ensuring those rules are covered in the ITIL change control/change management process run by IT and ensuring they are followed by the IT server management team), but infrastructure security does not actually do the patching.
Figure 1: Security Group RACI Chart
Let’s now focus on organizational size, resources and funding. Team size varies according to industry vertical, the scope of the infosec program and the risk appetite of executive leadership. Examples of security spending/funding as a percentage
of IT spending/funding include:
Financial services/insurance might be about 6-10 percent. The range is given due to the uncertainties around scope and risk appetite. However, companies that do a higher proportion of business online may have a higher range. For example, a large financial
services organization might spend around 12 percent because of this.
Retail could range from 4-6 percent, depending on online vs. brick and mortar. Online tends to be higher.
Manufacturing ranges typically sit between 2 percent and 4 percent.
Healthcare is very complex. Security spending depends on whether the company provides point-of-care” (e.g., a hospital or clinic), focuses on research and development or delivers material (pharmaceuticals, medical devices, etc.). Point-of-care enterprises
have historically underfunded security spending, and have (over the past decade) increased spending to compensate, so their percentages tend to be in flux. At present, their spending usually falls in the 4-6 percent window. Healthcare companies that
deliver material tend to have a security spending profile similar to manufacturing companies (2-4 percent). Those focused on research and development vary depending on their specific niche and whether they are a startup or a more established company
(e.g., Biogen, Abbvie, Allergan, etc.). These companies spend generally from 2-6 percent.
Technology support or online services vary depending on clientele. If they mostly support financial services companies, their numbers could sit in that higher range (6-10 percent), but if they serve manufacturing companies, their numbers may be lower
Important to note, companies that recently experienced a serious breach or security incident have much higher security spending than the percentages cited above. Which begs the question: Do you have any breaches or security incidents which may be useful
in making the case?
Previously, Gartner published a general, non-industry-specific metric that applies best to very large companies. And in this report, the recommendation was one information security full-time employee (FTE) per 1,000 employees.
While perhaps serviceable for large or enterprise-level organizations, this metric is less helpful for smaller companies because there are no economies of scale. Also, one element that adds to the cost of information security is the need to have distributed
security resources available, which is a situation you may confront. Generally, you need resources wherever your assets (devices, endpoints, servers, network infrastructure) exist. If you operate nationwide, this can mean additional resources are
needed proximate to your business locations.
The information security team is often placed (organizationally) under the CIO with its “home” in the IT department, even though its responsibilities are broader than just cybersecurity (e.g., they cover protection of sensitive information
in paper form too). Other companies place the team under the chief technology officer (CTO), chief financial officer (CFO) or chief risk officer (CRO). The key point is not the organizational location, but whether the CISO’s boss agrees information
security is important and has the organizational clout to provide strong support. If the answer to both questions is yes, security is well-positioned to succeed.
Many business processes in IT intersect with what the information security team does. The clearest example is change management. Any changes to the IT environment should go through change control or change management, and infosec should have representation
within the group that approves such changes. Additionally, IT often runs the IAM system, which is another area of intersection.
infosec and the IT should consider creating a division of responsibilities (DoR) document as to eliminate or lessen ambiguity or uncertainty where the respective responsibilities lie. To do this, IT should list all their business processes and functions,
and work with infosec to determine what role(s) each team plays in those processes. Doing this may result in some surprises, but that is an important outcome. In fact, Figure 1 reflects a DoR, although the full DoR should have additional descriptive
material explaining each row.
To help ensure an information security team is organized and resourced for success, consider:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.
September 19, 2023
By IANS Faculty
Discover the diversity of IANS Faculty's real-world expertise. Learn how our faculty members can help you solve your most challenging security issues.
September 14, 2023
Learn how to use a three-step approach to defending and managing public and private APIs while avoiding common mistakes.
September 12, 2023
Understand the main differences between first- and second-gen SAST tools and learn how to determine which will work best for your environment.