Where should the security function report? This is a frequent point of discussion in the security community. However, this implies that everybody has the same understanding of what a ‘security function’ should be doing, and also that an ‘ideal’ reporting structure exists.
The discussion tends to go off on tangents, as the security function’s mandate varies greatly by business sector and company, and even between business units within the same company.
There is a difference between security functions with a governance focus, setting policies and managing compliance, and security functions with an operational focus, managing security services. We can differentiate them again by mandate, i.e. whether they’re responsible for a company’s IT or for the enterprise at large, including its users.
A company of sufficient size may have all of these functions, while smaller ones may choose to concentrate security into one function, regardless of governance considerations. Such a decision will also be influenced by whether IT, and in turn security, are technology or business driven. (A technology-driven security function will almost inevitably end up under the umbrella of IT.)
Security resources may or may not have a direct reporting line into the security function. In many cases, they may only have a dotted line, or none at all. How much authority is granted by a ‘dotted line’ is again a function of the business organizational strategy.
In a full-fledged matrix organization, the ‘dotted line manager’ may have a technical authority and even set some of the staff’s goals, while in other situations the dotted line may result in informal consultations only.
Terminology may confuse things further. Security people refer to a security function that is outside IT, and operating on an enterprise mandate, as an ‘information security function’. It is an ‘IT security function’ when it is inside IT. Such denominations are far from uniform and seem like jargon outside the IT and security communities. The business may not care about such nomenclature.
Linking Role to Structure
A common structure is CISO reporting to CIO. This structure has advantages, such as a deep integration into the IT organization, potentially reducing friction with IT service delivery, as the security function is not seen as an outsider. On the other hand, it risks a conflict of interest, if not collusion, as both the security function and IT service delivery are under the same budget and presumably the same goals.
Establishing a security function with an enterprise scope, and a reporting line outside the CIO’s office, on the other hand, can result in a positive focus on policy and risk management, and a clear separation of duties between the CISO and IT service delivery. However, such a function risks creating a disconnect from the realities of IT service delivery, and can even be seen as an antagonist. Whoever has the nom-de-guerre CISO, it is almost inevitable that a security function within the IT organization still needs to exist.
Formal and Informal Authority
In reality, things can be less structured. The CISO, regardless of reporting structure, will often be considered the go-to person for any security questions. Managed intelligently, this isn’t necessarily bad.
Many stakeholders cannot be addressed from any single point in the corporate hierarchy. Any successful security function needs to maintain a strong network of contacts, alliances and stakeholders. Wherever the security function is located, it will require other internal and external actors to make changes. As a condition, for every stakeholder there needs to be business value in supporting the security function.
The security function is intended to provide oversight and be a driver of change. To be effective within its mandate, reporting structure is important, as is its prominence within the organization chart.
Stakeholders will perceive the function’s influence by whether it sits at the table of the decision-makers. A security function should report directly to the executive it is under, not be buried under layers of operations and risk management. Being in a euphemistically named ‘strategic’ or ‘advisory’ position is incompatible with the security function’s governance aspect and role as a driver of change.
While it is important to have clear roles, responsibilities and procedures, security problems, compared with other IT service disruptions, are comparatively rare, and there may not always be an established response plan. In a crisis, the CISO may have to assume authority to ensure a swift resolution, so working through reporting lines and hierarchies is not always efficient. A security function can only work if connected with the rest of the organization through more than just reporting lines.
Preventing security problems efficiently and effectively is why we have a CISO in the first place.
Further reading and references
1. BSI Standard 100-1, ‘Information Security Management Systems’, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/BSIStandards/standard_100-1_e_pdf.pdf?__blob=publicationFile (retrieved 2015-01-05)
2. NIST Special Publication 800-39, ‘Managing Information Security Risk: Organization, Mission and Information System View’, http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf (retrieved 2015-01-05)
3. ISO/IEC 27001:2013, http://www.iso.org/iso/catalogue_detail?csnumber=54534 (retrieved 2015-01-05)