Transitioning to a centralized IT shared services model requires establishing well-defined services, service levels, performance metrics and governance. This piece explains how to design a shared services model to serve customers efficiently, effectively,
and securely.
Defining Shared Services
A shared service center is a customer-oriented business unit that provides a defined set of services at an agreed-on service level. These services are provided to internal customers (i.e., other business units or groups). The service level is measured
by several metrics. The shared service center defines success with a key performance indicator (KPI), which is the one metric most indicative of the shared service’s performance. Concerns are defined by a key risk indicator (KRI), or the one
metric most representative of increasing risk exposures. For example, a shared service may deliver software to the business and be measured on feature velocity (a KPI) and time-to-remediate vulnerabilities (a KRI).
Shared services generally include:
- IT infrastructure: Service desk, telephony, networking, endpoint management, etc.
- Software delivery: Support, application development, operations, etc.
- Business services: Core business processes, financial services, supply chain, marketing, etc.
- Centers of Excellence (CoEs): Business function advisory and expertise, strategy, etc.
Securing Shared Services
A typical shared services model features:
- IT infrastructure services: IT owns and operates the technology, and IT implements and maintains technical controls.
- A cybersecurity CoE: Security defines the security posture and reflects this posture in security control requirements.
- A governance, risk management and compliance (GRC) CoE. The GRC CoE informs both IT and security of regulations, requirements and resulting obligations. GRC then audits the controls against the obligations.
For example, the Payment Card Industry Data Security Standard (PCI DSS) requires multifactor authentication (MFA). GRC is responsible for PCI DSS compliance and owns the obligation. Security interprets the obligation as multifactor for specific authentications
using a phone-based one-time password (OTP). IT implements and operates products for MFA, which it configures and maintains on the appropriate IT infrastructure. IT provides a metric or other evidence to demonstrate this control’s efficacy.
GRC audits the MFA in collaboration with the PCI DSS qualified security assessor (QSA).
To be effective as a CoE, ideally, the security team and IT team should have the following:
- Security capability: This is a set of related and mutually reinforcing security controls the organization implements with people, process, and technology. Examples include identity and access management (IAM), monitoring and logging, and vulnerability
management.
- Security capability owner: This is the person responsible for the vision, strategy, and architecture of the capability.
- Security control: This is one unit of process and technology within a capability that addresses specific risks and/or obligations. For example, multifactor policy and technology would fall under the IAM capability.
- Security control owner: This is the person accountable for ensuring the control is implemented, operated, and maintained correctly. The security control owner may also be the advocate.
- Security advocate: This is a member of the security team who focuses on getting practices into the hands of the workforce, and advocating for the needs of the IT shared service. The advocate works directly with the champion.
- Security champion: This is a member of the IT shared service, who collaborates with the security advocate to determine the best approach for implementing the control. Ideally, each shared service has a defined champion.
- Process owner: This is a member of the IT shared service responsible for the operation of the security control. For example, the router administrator is responsible for configuring and maintaining MFA for console access.
- Operational metrics: These are measures provided by shared services to demonstrate IT is providing the control with the service to the agreed service level. This includes a defined KPI and KRI (these may be the same metric, with risk or performance
being a measure along the scale).
In the above example, the security function is a CoE with no direct-line responsibilities. In some situations, the security team may also provide services as a shared service similar to IT.
Example Roles and Processes
The roles for any given security capability or IT service should be defined and agreed on. Use a RASCI matrix to capture the information (see Figure 1 for an example).
The processes for any given security capability or IT service should be defined and agreed on. Consider use a Supplier-Input-Process-Output-Customer (SIPOC) matrix. This exercise enables the team to reimagine IT as a customer-oriented shared service.
Issues to Avoid with Shared Services
To be successful with shared services, organizations should try to avoid:
- Offering less-than-well-defined services. Well-defined IT processes with mature tooling and staffing are ideal for shared services. Emerging technologies, highly customizable processes or ad hoc approaches are not. Begin securing the well-known and
well-proven services.
- Over-committing the security advocate. The transfer of practices, knowledge and culture between security and IT depends on the relationships and trust between both business units, as embodied by the advocate and champion. A typical advocate can successfully
influence with five to seven champions. At higher numbers, the relationships suffer, which will show up in misaligned expectations and execution.
- Letting shared responsibilities become no one’s responsibilities. Explicitly define the security champion and process owner. Each shared service should have one champion and one process owner. This may be the same person, but the responsibility
should not be defused across the team supporting the shared service.
- Positioning the security CoE to audit IT. The relationships and trust between security and IT are critical success factors. Be careful to avoid antagonism or us-versus-them thinking between the two functions, such as having security auditing and blaming
IT. GRC and external audit should fulfill this role.
- Failing to measure what matters. Define service-level metrics and identify the KPI and KRI within the metric set. This may be done as a collaboration between the security advocate and security champion. Ensure the metrics are easy to collect, meaningful,
reviewed and acted on. Security in a shared services model is security by service level.
Transitioning to an IT Shared Services Model
The time during the transition from traditional IT to shared services IT will be the hardest part of this process. Well-governed security capabilities will apply to well-defined IT services in a CoE. During the transition, however, the security team will
have CoE responsibilities and legacy responsibilities, potentially including managing security operations and IT line duties. Plan for this and, where possible, consider separating the team and duties between CoE and legacy to facilitate change and
minimize confusion.
How to Succeed with an IT Shared Services Model
To help ensure security is well-positioned to succeed in the shared services environment, consider:
- Defining security capabilities and associated controls. Map these to the IT shared services and establish security requirements for the IT shared services.
- Establishing security advocates and security champions. These relationships are crucial in implementing controls that are minimal, usable, error-proof and cost-effective.
- Avoiding doing too much too fast. The move to a shared services model will occur over years and, even in mature organizations, is a continuing and ongoing evolution. Clarify which security aspects the CoE can control and which it cannot control.
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.