Focused guidance
Azure Platform Modernisation
Led a transformation of governance and Azure architecture to help Brain in Hand operate as a regulated healthcare SaaS platform aligned with GDPR and NHS expectations.
Useful for
Overview
The work brought organisational governance, data protection, identity, infrastructure, resilience and operational practice into a single target state. The aim was not just to make the platform more secure, but to make the company able to evidence how the platform was governed, operated and improved.
Context
Brain in Hand had grown from an early-stage product into a platform supporting thousands of users, including services that handled sensitive and special category data.
As the business matured and began engaging with NHS organisations, expectations around data protection, governance, operational resilience and assurance increased significantly. The platform was technically capable, but the company needed a clearer governance model and a cloud architecture that could support regulated healthcare operation.
This required coordinated change across both the organisation and the technology. Policies, risk management, data protection evidence, identity controls, Azure architecture and day-to-day engineering practice all needed to move in the same direction.
Approach
The first step was to define a target state for governance and architecture rather than attempting isolated fixes without a shared direction.
That target state included:
- governance aligned with GDPR and NHS expectations
- data protection evidence, including a DPIA and data-flow mapping
- least-privilege access and zero trust principles
- Azure identity and access controls based on RBAC and Privileged Identity Management
- a cloud platform that could support resilience, recovery and controlled change
- operational practices for monitoring, logging, incident management and disaster recovery
From there, I carried out a structured gap analysis across organisational governance and the existing Azure environment. Each gap was assessed against the risk of leaving it unresolved, which allowed the roadmap to be prioritised by business and compliance impact rather than technical preference.
This ensured governance and architecture evolved together. Policies and data-protection decisions were translated into platform controls, while technical constraints informed practical governance and operational procedures.
Implementation
On the governance side, I rebuilt company-wide policies and introduced a formal risk-management framework aligned with GDPR and NHS expectations. A key part of this work was producing a comprehensive DPIA, mapping data flows across the platform and identifying where controls needed to be strengthened or introduced.
In parallel, the Azure environment was re-architected to meet the defined security and compliance requirements. Identity and access management was central to the design, with RBAC and Privileged Identity Management used to enforce least-privilege access and move the platform towards a zero trust operating model.
The infrastructure was rebuilt using Bicep so environments could be provisioned in a consistent, repeatable and controlled way. This improved the link between governance decisions and the actual state of the platform, reducing reliance on manual configuration and making future change easier to review.
The platform architecture was also redesigned to improve resilience and recoverability. This included region-aware deployment patterns, failover capability and strengthening the data layer using MongoDB Atlas for high availability and automated recovery.
Operational practices were formalised around monitoring, logging, incident management and disaster recovery. This helped ensure that the platform could be operated reliably in a regulated environment, and that evidence existed to support customer, NHS and data-protection conversations.
My Contribution
I led the transformation end to end across organisational governance and technical architecture.
This included:
- defining the target governance model
- carrying out governance and Azure gap analysis
- establishing the compliance and remediation roadmap
- rebuilding company policies and risk-management practices
- producing the DPIA and supporting data-flow evidence
- designing the Azure identity, access and privilege model
- directing the Azure re-architecture and Bicep infrastructure approach
- aligning engineering practices with governance, resilience and compliance requirements
- working with engineering teams and external stakeholders to keep delivery practical
The key contribution was connecting governance intent to implementable platform change. The work was not treated as a documentation exercise on one side and an architecture exercise on the other; both were designed to reinforce each other.
Outcomes
The work helped transform Brain in Hand from an early-stage platform into a more secure, resilient and governable SaaS service suitable for regulated healthcare environments.
The platform was better able to support NHS conversations, GDPR expectations, sensitive-data handling and operational assurance. The company also gained a clearer evidence base for explaining how the service was governed, how risks were managed and how the cloud platform supported the required controls.
The most important outcome was alignment. Governance, architecture and day-to-day engineering practice moved into the same operating model, allowing the platform to scale with greater confidence.
How this shaped my approach
This work changed how I think about SaaS delivery.
Before this, it was easy to see the main challenge as building and delivering the software. The deeper lesson was that in a serious SaaS environment, especially where sensitive data and regulated customers are involved, delivery is only part of the problem.
The company also needs to know how decisions are made, how risk is understood, how data is protected, how access is controlled, how incidents are handled and how the platform can be operated with evidence rather than assumption.
That experience shaped the governance-led approach behind Brokenhouse. The goal is not to slow delivery down with paperwork. It is to make the organisation safer, clearer and easier to trust as the product grows. Good SaaS delivery needs the platform, governance and operating model to mature together.
What good looked like
Good was not simply a redesigned Azure environment or a completed set of documents. Good meant the company could explain and evidence how regulated SaaS operation worked in practice.
That included:
- a clear target state for governance and cloud architecture
- policy and risk-management structures that matched GDPR and NHS expectations
- DPIA and data-flow evidence connected to real platform design
- least-privilege access enforced through Azure RBAC and PIM
- repeatable infrastructure using Bicep
- improved resilience through region-aware design and recovery planning
- operational processes for monitoring, incident management and disaster recovery
- engineering practices that reflected governance decisions
Reusable Lessons
Governance and architecture need to evolve together. In regulated SaaS, a policy that is not reflected in the platform becomes theatre, while a platform control that is not backed by governance is hard to explain to customers, auditors or partners.
DPIA work is also architecture work. Once data flows, storage locations, processors and operational access are understood, they naturally shape identity, logging, backup, support and recovery decisions.
The final lesson is that modernisation should be risk-led. The roadmap is stronger when it is prioritised by the risk of not implementing a control, rather than by what is technically interesting or easiest to change.
How Brokenhouse helps
Turn this into a practical plan.
I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.
Talk through your situationNext guidance
Related decisions to work through
Use containers as the default packaging stance. They give the product a flexible route from POC to Pilot to Production without forcing the final hosting decision too early.
POC, Pilot and Production are partly cost-control stages. Each step accepts more cost only when the risk, customer expectation or operational promise justifies it.