Using a Risk Register to select and drive action is a great way to securely manage a product portfolio; but how do you identify and prioritise your must-fix items? Let me tell you how I did it.
| What is a Risk Register? |
| A Risk Register, also known as a risk log, is a structured document used in project management to record potential risks, their impact, and planned responses. It helps organisation’s identify, assess, and manage risks throughout a project's lifecycle, ensuring proactive measures are taken to mitigate potential challenges. In a security context, the Register records key security risks to operation and data and actions toward control. |
My Journey in Digital Product Security
A few years back, as a staff engineer in an Ed-tech company, I took on the challenge of raising digital product security. You can read here, how I chose to drive it using an small engineering team.
Having pitched, chartered, and formed the team, we were ready to begin. I had 6 months to prove our value. When initiatives start, it's challenging to gain traction, making it difficult to earn the trust and buy-in needed to implement real change. For the team to demonstrate its worth, we needed to find the key moves that everyone could get behind.
In the face of complex changes, even the best times can derail. I had a vision and a team, but I needed a plan that would inspire and gain everyone's support.
(The Lippitt-Knoster Model for Managing Complex Change)
Identifying Key Security Concerns
To get trust, I needed to identify what work was valuable and achievable in that time - or shorter. Even better, if I found that out in collaboration with others I could start to build community and consensus.
I identified 4 areas of focus and a key question for each with the aim of workshopping each one.
External : What do we need to be better protected from external attacks?
Internal: What do we need to avoid exposure of personal data and reputation damage by staff?
Compliant: What do we need to achieve high levels of compliance with law and regulations?
Delivery Process: What do we need to ensure our squads keep us safe whilst delivering new features?
Engaging the key contributors
I thought about who should discuss each question. Each session would focus on answering a key question, but there was deeper work than just building a list. Real security is a mix of risk identification, tradeoffs, and an understanding of what systems might do.
As well as experts, I also needed to hear from the teams involved and those impacted by security risks and the potential change: leadership and those designing, building and operating our products and platform.
I invited experts, the involved, and the impacted for each session, and began to work out how I could flow each question into the answers I needed.
There were a few outcomes I wanted from my workshops. Looking broad to understand the risk space the business was in, zooming in on what my team should tackle and to grow care and involvement in security.
With that in mind I set up each workshop to first generate a pool of issues or gaps. And then to ask the group to segment and prioritise what we had identified.
The below diagrams show the flow of each of the four workshops.
Achieving Consensus and Direction
There were weeks of preparation and hours of meetings. It was worth it. We found strong agreement, buy-in and direction
Not only did we have a strong Risk Register, we also were able to form a stakeholder-led steering-group to guide how we approached controlling the risks. We also had clearer agreement of what problems belonged to which teams and a backlog for my new team
Driving Change with a Robust Risk Register
The impact of an action is the things it makes better. A risk register is pointless unless it drives change. Looking back, I recall how the register and the stakeholders helped shape the work the Engineering Security team cared most about.
We took immediate action to get better management of Production Database credentials, and secured other access and passwords. We build tooling to provide an overview of the state of vulnerabilities in 3rd party libraries across the estate, driving updates and further care.
more longterm, It drove a long thread of work that began with an assessment of the data each team held and drove towards a guide to help the teams make good choices for their data and products. Our Risk Register kept us joined up and always looking towards fixing the biggest most critical gaps.
