Compliance by design

The way we traditionally ‘do’ compliance is a disaster. Not only is it painful, but it also doesn’t work particularly well: Its prescriptive, reactive, box-ticking attitude does nothing to support a business in delivering high quality products at pace, it ignores customers and their expectations, it does not add value to society at large, and ultimately it does nothing to enable efficient and effective compliance operations themselves.
But there is a better way: compliance by design / continuous compliance.

A better way to ‘do’ compliance

Compliance by design / Continuous compliance

The word ‘compliance’ alone fills many product teams with fear and loathing: the way compliance is traditionally implemented is simply not suitable to cater for the today’s demands of fast paced product development, global supply chains, aggressive competition and increasingly complex product and compliance requirements, which are no longer easily dis-entangelabe. But there is a better way: compliance by design, or, continuous compliance.

Compliance by design playbook

This free playbook (still a bit ‘draft’ – I’m sorry) outlines ideas on why and how we must and can make compliance not only less painful, but actually valuable (and more robust) by heavily drawing on methodologies, value and principles we know work across other disciplines, such as lean, agile, user centricity, DevOps, system thinking etc. and apply them to compliance.

Download playbook (PDF)

Presentation

A better way for compliance.

Conference talk on why we need to shift our stance towards compliance, why a new, better approach can be a source of competitive advantage, how compliance by design | continuous compliance looks like in practice and how we can get there.

Presentation deck (PDF) without speakernotes and with speakernotes.

Other useful resources, see below

What does it cover?

A new way to look at compliance, and why we need to care
An outline of the state of compliance and why the traditional approach does not work
A proposed new approach to compliance covering culture and process and how to ‘get’ there, focusing on ‘shifting’ culture (mindset) and process

A word for the weary: This is NOT a new methodology, in fact, it’s the same old agile / lean thinking that we have so successfully applied to break down the horribly inefficient and stifling dev-ops boundaries, and extends all this ‘good stuff’ now towards compliance.

Why bother?

Compliance is here to stay
Compliance is getting more complex
Compliance is valuable (beyond you not loosing that license to operate or not getting sued)

Traditional compliance processes cannot cater for the demands of fast paced, reliable, high quality product delivery in an environment of constant product and compliance requirement change.

What and why?

Continuous compliance / Compliance by design enables delivery of desirable business outcomes at lower cost, increased compliance quality and increased resilience (if we fuck up).

Generally speaking we need to consider compliance as part of the product design and implementation process as well as subsequent operation of the product. So we need to think of compliance implementation and compliance operation.

We need a shift from assuring compliance to enabling compliant value delivery.

We achieve this by shifting culture and process

Culture from reactive, prescriptive compliance assurance to proactive, value focussed achievement of organisational goals.
Process from siloed, one-off, end-of-process, gate-keeping to integrated, continuous, enablement that support rather than impedes lean and agile delivery.

We need seamless compliance, upstream and throughout. As we work with ‘any’ other discipline.

How

Shifting culture

Define stance on ethics and risks
Define desirable outcomes / goals
Identify compliance concerns and priorities
Identify compliance stakeholders
Align with compliance stakeholders (as-is goals, concerns and process, where you need them to shift). Address concerns.

Adapting process

Adopt agile (iterative!) delivery lifecycle standard best practices, but specifically

in discovery define identify compliance concerns and potential risks and impact
in the subsequent inception identify top-level compliance requirements and compliance stakeholders
during analysis and design activities to refine requirements and define solutions
during delivery and quality assurance deliver compliance features and assure compliance
as part of deployment and release conduct any final compliance assurance required (note that ideally you bring all activities forwards to prevent potentially blocking late gates)
during operation monitor compliance performance and status, react to change in the compliance requirements, and manage incidents and at hoc audit or compliance assessment

Apply lean principles
Shift blocking concerns upwards, and make them continuous. Keep development cycles as short as possible. (Allow, where necessary for specific larger assurance cycles or ad hoc compliance activities).

Build on a foundation agile best practices
Apply these practices to delivery and operation, then transfer to / include compliance.
Continuously design, develop, integrate, test and assure, deploy, release (if you must release on demand as and when ready).

Draw what you can from DevOps / automate everything
Underpin compliance with infrastructure (tooling / process) to enable continuous verification, validation and assurance. This includes a heavy focus on process automation, capabilities to trace needs-requirements-risk-features-tests-certification and automatically create required artefacts, as well as system observability so teams can monitor system performance (compliance and other) and act accordingly.

Contextualise
One-size does not fit all. The approach to continuous compliance will need to be tailored to fit organisation and initiative.

Transform step by step
Avoid radical change. Take a step by step approach to moving towards continuous compliance.

Ethical Product Management

A presentation I gave at the 2023 Product World on ethical product management and what ‘ethics’ mean for product teams on a day to day basis. In this talk I provide a ‘north star’ of what ‘ethical’ could mean, and a framework on how to make difficult ethical choices when designing, developing and operating products and services.

Watch presentation

Bringing product management to DevOps

A presentation I gave at DevOps Days on how DevOps can add value to organisation beyond the narrow definition of infrastructure: I demonstrate why we need to expand the view of the DevOps pipeline to the entire value chain and how this can turn our ‘pipeline’ into a source of competitive advantage (and why, consequently we need to manage it as a product).

As part of this presentation I present a case study from the medical device industry where collaboration between DevOps, compliance and other disciplines gave one of my clients a major competitive edge.

Watch presentation

The Chinese Cyber Security Regime

A series of podcast episodes during which Chinese Cyber Security expert Dr. Michael D. Frick and I discuss the nature and implications of the Chinese Cyber Security Regime.

Listen to podcast