Research for setting up an organization for security governance

Alpha version

Organization

B2B, SaaS, 100-130 FTE

Challenges

Company challenge

Our multinational software company changed their strategy from building on-premise software to building SaaS products. The implication of this decision was that most security responsibilities and legal responsibilities of protecting customer data would transfer from our customers to us: It increased the risks to our business, from a technical but also a legal and contractual perspective.

At the same time, customers demanded from the company the implementation of a systematic approach for security governance such as ISO 27001.

My challenges

My new role was to support the CISO in designing, maintaining, and improving a system for security governance. In this role, I was facing many challenges: Both the CISO and I were new to our roles and had no prior exposure to security governance. The CISO was also the CTO of the company, who was assigned the additional role of CISO. Both the CISO/CTO and I did not receive any training for our new roles.

Furthermore, the team in scope had limited documentation about their approach to managing security, and the existing approach was not designed for scaling up to other teams. The existing approach was set up by two managers that had left the company. In addition, the company had no plan on how to maintain and improve our security posture or how to scale up security governance to more teams.

In order to set up the system to be ready for upcoming certification audits, my challenge was to find out which “organizational features” the company needed to modify or implement in order to end up with a systematic management approach for security governance, risk, and compliance.

Roles

  • My role: Security governance officer (i.e., product owner of security governance, with product manager tasks)
  • Team members: CISO/CTO, with supporting members: Cloud infrastructure team, developers, legal council, HR, office desk

Constraints

  • No managers or employees with a background in security or security governance
  • No budget for education, tooling, or third party support
  • Requirement to limit interaction with cloud team and developers to a minimum
  • No management plan or objectives other than certification for the management system

My approach

Given the context and constraints there was a clear expectation I was to operate as a self-sustaining team of one, with minimal room for collaboration. Therefore, my research methods needed to be methods that minimized the time spent by internal stakeholders.

As a team of one, I set my own objectives and scope, designed my own processes, and very heavily relied on desk research using publicly available sources. In terms of deliverables, in the first phases I focused on delivering well-researched, generic frameworks and documentation. I would then use this foundation in next iterations to produce company-specific deliverables.

Phase 1: Scope and objective

In order to design a suitable future governance system, I supported the CISO/CTO in verbalizing a scope or vision. I used a concept objective with a broad scope of multiple development teams being governed by this governance system within 3 years. The CISO/CTO confirmed I could use this as a concept objective. I used a future scope that covers more teams so that we end up with a framework that is more easy to scale.

Phase 2: Exploratory research – Desk research

First, I researched the security management standard using external sources, and then reviewed our existing internal documentation. This allowed me to better understand the purpose of our existing documentation, my role, and how to get to well defined processes for security governance.

Understanding the context

Next, I used a combination of desk research and co-creation to create a stakeholder analysis. In the stakeholder analysis I made sure we covered legal current and upcoming obligations, customer requirements, prospect expectations, requirements from the security standard, and needs from the various internal stakeholders. The stakeholder analysis helped me to understand the context, but also served as input for a later phase: Setting objectives and constraints for the design and the operation of our organization.

After that, I continued my desk research to deeply understand all other organizational features we needed to design and implement. To facilitate collaboration, I documented all my learnings in a wiki, and continued to do this with all other deliverables.

Phase 3: Design an initial concept for a management system

Hypothesis

Based on my research, I was now able to define my hypothesis for designing the system: Good governance systems all share a broad set of basic elements that are the same for all organizations; tailoring of governance systems mostly happens within the configuration of these elements, and by adding or removing a limited set of elements that are specific to that organization. I would use the moments of collaboration with the people in scope to test elements of my system, and use external audits to test my hypothesis.

Design approach

Based on my hypothesis, I decided on an iterative approach for designing the governance organization: Start building a solid generic foundation for a governance system in a first iteration, and then build in and bolt on organizational specifics during later iterations. This allowed me to involve stakeholders at the times and for the design decisions where it mattered the most, while being able to make progress on the rest of the system.

First and second iteration of prototype, based on desk research

Based on the desk research, I distilled the requirements for management systems in general (e.g. contextual analysis, policy, risk management, communication, performance management), and then designed a first prototype for a generic management system, consisting of its broad and generic outlines. Then, I added a layer of organization-specific objectives and constraints, based on the requirements distilled from the stakeholder analysis.

Next iterations, based on co-creation and interviews

For the next iterations, I held a limited number of focused co-creation sessions and interviews with relevant colleagues. My approach was to reduce the time stakeholders spent on collaborating with me, by discussing only well-researched prototype materials. For example flowcharts, matrices, templates, example policies, etc. This way I maximized the impact of these collaborations and limited the time I needed from them. Their feedback helped me color in some of the sections and further improve the management system design.

Phase 4: Research the organizational gaps

Which business processes and measures are missing from our foundation, and which issues do these business processes and measures have?

I decided to research and document the current state: Which business processes and measures we already had in place, again by doing a combination of desk research (documentation, customer contracts, user stories, etc.), interviews, and co-creation. This allowed me to compare the current situation to the standard, to the obligations, and to external expectations. Any discrepancies I would find, were labelled as risks to our organization.

Phase 5: Document and track the risks

Organizational gaps can lead to compliance issues or sub-optimal results; the standard considers these to be risks to our organization. I used a ticketing system (Jira) to document these risks, and modified a Kanban board so that I could create structure in researching the various types of risks, plan measures, and track their progress. Based on desk research, I also designed a new risk assessment process to facilitate the CISO, and a spreadsheet to track progress over the years.

Result

  • Designed a well-documented, structured, and scalable management system for security governance.
  • Clear requirements for all aspects of a governance system.
  • Design and implementation of foundational processes such as stakeholder analyses and risk assessments.
  • Structured inventory of organizational gaps.
  • Knowledge management system built for collaboration, with data from the Jira ticketing system integrated into the Confluence wiki.

Impact

  • My work supported the CISO in understanding the organization and operation of the business function, and the forces that affect its operation.
  • My process designs, flowcharts, matrices, and templates facilitated the CISO’s decision-making, so that he could combine the role with being CTO.
  • My risk assessment process enabled the CISO to assess risks, plan measures, and track progress per ticket, but also in aggregate and across years.
  • By applying the feedback from external auditors for improving our system, we managed to pass the audits from the last two years without a single non-conformity, which is a measure for the reliability and completeness of our governance system.
  • The foundation I built, enabled us to remain certified for ISO 27001 security management for more than 7 years, and to even add more certifications (ISO 27017, ISO 27018, SOC2 and SOC3).

Reflection

I found this new position to be extremely challenging, as I was basically building a business function from scratch with many constraints and lack of organizational support. This led to a lot of friction between me and the CISO.

As I first thought our discussions could become more constructive if we both knew more about the subject matter, I tried to solve it by gaining more expertise on security management, and sharing my knowledge with the CISO. I learned that knowledge was not relevant in getting alignment. Later, I experimented with various communication tactics to bring the CISO on board. Today, I still use most of the tactics that were successful for making progress. In hindsight I could have come to alignment faster if I had put more focus on understanding his motivations, underlying needs, and management style.