#011: Risk Management, Security and Compliance
Embrace and collaborate with "legal" or you won't make it.
Risk management deals with legal and security risks. As a product manager it is essential to understand how to deal with it.
The reason is that a PM owns the end-to-end responsibility to ship the product or feature.
Unawareness regarding risk management will certainly delay shipping the product or - in the worst case - can kill the product.
Even though as a PM you are neither a lawyer nor a security officer you need to know how to navigate risk.
Navigating risk does not mean you need to have polished endless slide shows with flow charts on that topic.
Simply know when you need to slow down a bit to understand a risk component in detail or involve your legal department, a risk officer or an external lawyer or consultant before going full steam on building and shipping.
For instance, you don’t want your company to pay a $10M fine or 4 % of your total global turnover because you thought since you are based in the U.S you don’t need to understand GDPR (= General Data Protection Regulation) while selling in the EU.
The following 4 topics are the pillars of risk management:
Legal and compliance aspects
Vulnerability management
Identity and access management
Change management
Let’s address them in detail.
1. Legal and compliance
In short: Be aware of the law and, if available, internal company guidelines.
(If no internal guidlines are available, this is the moment to set them up).
If you work in a heavily regulated industry such as the finance, health or the automotive industry then you should gain a solid understanding of the compliance-processes to bring a product to market.
If you’re a PM in a corporation you might have entire teams or departments that will assist you in the building process to ensure compliance.
If you are a founder or intrapreneur you may need to setup certain processes yourself.
But even in less regulated industries there are legal aspects to understand.
The GDPR-example above basically already applies to any company that has a website which is available from within the EU.
Thus, proactively understand legal aspects and don’t wait until you receive a notice from authorities that your company will be audited.
2. Vulnerability management
Define how to deal with an incident in a reactive but also proactive way.
Hence, it’s not only about your incident-response process but also how you detect, fix and prevent vulnerabilities from being exploited.
During the building process it involves:
Secure coding practices, e.g. coding standards, security standarts (such as OWASP).
Vulnerability management of your suppliers: Are your systems hosted on AWS or the Azure Cloud?
How do these companies proactively ensure your software is “safe“, how do they patch their systems, how and when do they notify you if there was an incident on their systems? What about other suppliers you have?
Are there data processings agreements (DPAs) in place?
Example:
Is your CRM, CMS, or customer support software from a trustworthy company or is it from your best friend’s startup and you are her first customer yet you are about to host your customers’ most private and sensitive data on her servers?
Penetration tests, bounty programs, read teaming
Classification of data according to sensitivity (a person’s credit card number may be more sensitive than her age)
Identity and access management (see below)
During product development and delivery, vulnerability management comprises of:
Quality gates (e.g. encrypted data streams, segregation of duties regarding deployment pipelines, monitoring and alerting systems and how to respond to such alerts, etc).
Change management (see below)
Test and release management
As mentioned before, you need to define a proper incident-response process that works in practice. If an incident happens you need to quickly get an overview, mitigate and then solve the issue, i.e.
Overview: how does the organization define the criticality of the incident?
If high criticality: who informs internally whom, when and through which channel?
Who informs externally (e.g. the customers)?
What are the legal deadlines (e.g. if all your financial customer data got stolen)?
Who informs authorities if necessary?
Who are the deputies of the involved roles in case people are sick or on holidays?
Is there an on-call policy necessary, if yes, set up the process compliant with labor laws in your country (in most countries you are not allowed to call your staff at 2AM in the morning and make them work without a proper agreement and compensation structure in place).
3. Identity and access management (IAM)
Define the different roles, accesses and approvals.
Start with categorizing systems and data.
For instance your analytics tool will provide access to a different kind of data than your database used in production which again hosts different data than your CMS or ticketing system used for customer support.
It is convenient to have a categorization regarding criticality of a system and sensitivity of data.
Once you understand both criticality of systems and sensitivity of data hosted on a system or generated by a service, you can define corresponding roles.
Typical roles are “viewer”/”observer”, restricted “editor” and “administrator”.
Now you can define policies for those roles:
Which (other role) approves them and which role is the deputy?
For how long can or should a role be approved?
How often should the role and access management be reviewed and revalidated?
How do you ensure the revalidation process takes place and how do you document it?
A standard principle to apply is the “need to know“ and “need to have“ principles which follow the idea of always granting the “least privileged” but necessary access for a role.
Your goal here must be to minimize the potential blast radius by design in case of an attack or incident.
Thus, you must minimize the potential damage that can happen due to human errors.
For example, if none of your developers has permanent access to the production database then they will never be able to accidentally mess it up.
Or if it is impossible to approve a merge request by the requester (i.e. segregation of duties) you drastically minimize the chance that code accidentally gets merged into a master branch, etc.
In early-stage startups or innovation projects it is often wrongly believed that the person who sits highest in the hierarchy should have all the rights and can approve everything.
However, that person often is the most visible from the outside and, thus, more exposed to be the target of vulnerability attacks.
In general, as your product scales you have to scale your IAM processes.
As a 4 person startup the process should be fairly simple.
The important aspect here is that you are aware that a process needs to be put in place, probably, as soon as you process customer data in production.
4. Change management
Define how change of your product happens: feature development, bug fixing, testing and releases.
Typically this involves all steps from specification to delivery to production, e.g. definition and specification, implementation, testing and release (and sometimes subsequent monitoring).
Again, not only the product management process itself is important but also approvals and role management.
A coherent development pipeline has end-to-end traceability which implies that no coding takes place without a traceable and hence, documented, “mandate“, e.g. a PBI (product backlog item) in Jira, Azure board or similar.
(Be aware, a PBI is not the same as a user story; more on that in a later post.)
Traceability also implies that you have proper “audit trails“ and logs in place, i.e. a way to prove who did what and when, e.g. who approved a pull or merge request, who approved a user acceptance test (UAT), who approved a deployment to production.
Further, define how quality assurance, test and release management takes place:
Local testing, unit testing, regression and integration testing, end-to-end testing, UAT, pre-production testing, etc.
Final note:
Such a process will never be perfect.
Especially if there is an incident, there will always be chaos and nervosity involved.
The most important point here is probably that awareness is crucial: Be aware that incidents can and do happen, think through the process and how to prevent incidents, protect the downside, be proactive, always think two steps ahead.
If you’d like to learn more, there are 3 ways I can help you:
Subscribe to this newsletter if you want to get actionable tips on software product management.
Email me at danielschmitter@substack.com to provide suggestions about blog topics.
Follow or connect with me on LinkedIn here.