Notes from live cloud, infrastructure and data-centre programmes. The same posts as on LinkedIn.
Data residency
Your data is hosted in Europe. So you are GDPR-compliant, right?
Not necessarily.
In international cloud implementations, one of the most important practical questions is not simply where the server is located.
It is: where can the data go, and who can access it?
Consider a seemingly straightforward cloud deployment:
- Production workloads run in an EU data centre.
- Backups are replicated to another region.
- A disaster-recovery environment is hosted elsewhere.
- An international support team has privileged access.
- Logs and monitoring data are sent to a central platform.
The primary workload may remain in Europe, while other parts of the service introduce additional privacy, security or international-transfer questions.
That is why I believe data residency should be considered across the entire service architecture, not just the primary hosting location.
During implementation, I would want clear answers to questions such as:
- Where are production data, backups and replicas stored?
- Who can access them, including remotely?
- Where are logs, metadata and identity services processed?
- Which suppliers and subprocessors are involved?
- Have the relevant transfer and security requirements been assessed?
These are architecture and delivery questions as much as compliance questions.
A cloud design is not complete simply because the infrastructure is running.
It must also operate within the agreed data protection and security boundaries.
Building a data centre is often presented as an infrastructure challenge, but it is much more than that.
During my career I have been involved in data-centre construction, renewal, infrastructure rollout, testing, customer migration and operations. I have also worked with full BWSE responsibility — including Security — during data-centre construction.
One of the biggest lessons is that security cannot be bolted onto the building after the technical design is finished. Physical security, network security, identity, access, monitoring, segregation, resilience, operational procedures, and customer requirements all need to connect.
And the programme needs to consider what happens after construction:
• How will customers be onboarded?
• How will access be approved?
• How will equipment be introduced?
• How will vulnerabilities be handled?
• How will changes be controlled?
• And eventually: how will customers and equipment be removed securely?
The best data-centre programmes therefore treat security as a lifecycle.
Design → build → test → operate → change → decommission.
That mindset reduces risk and makes the resulting service far easier to govern.
#DataCentre #SecurityByDesign #ISO27001 #ISO9001 #Infrastructure #ProgramManagement #Cloud
Running large cloud programmes under extreme pressure taught me that success comes from tight planning combined with the willingness to adjust every single week.
A solid plan gives a programme direction, structure and clear accountability. But in complex cloud environments, things rarely develop exactly as expected. Priorities change, dependencies move, resources become constrained, technical issues emerge and customer expectations evolve.
The key is not to abandon the plan when this happens — it is to adapt it intelligently.
For me, that means continuously reviewing priorities, dependencies, risks, resources and milestones, while keeping the team focused on the outcomes that really matter.
Strong programme management is therefore not about following a plan blindly. It is about having enough control to know when you need to change course — and enough leadership to bring people with you when you do.
Plan with discipline, adapt with confidence, deliver with purpose.
ISO 27017 is particularly interesting for anyone managing cloud delivery because it forces us to think beyond generic information security.
Cloud introduces shared responsibilities.
Who protects the physical infrastructure? Who manages the hypervisor or platform? Who manages identities? Who is responsible for the workload? Who owns the data? Who responds when something goes wrong?
If those questions are unclear, a RACI matrix alone will not save the programme.
I have seen throughout my cloud and data-centre career that unclear ownership creates delays, exceptions and operational risk.
That is why I believe cloud programmes should translate security principles into practical delivery controls:
• clear responsibility boundaries
• defined access and privileged access management
• vulnerability management
• logging and monitoring
• secure configuration
• incident and change processes
• evidence and auditability
• controlled onboarding and offboarding
The real value of ISO 27017 thinking is not the certificate.
It is creating a cloud service where security responsibilities are understood before the first customer goes live.
#ISO27017 #ISO27001 #CloudSecurity #CloudManagement #ProgramManagement #SecurityByDesign
Security should not be a workstream that appears halfway through a cloud programme.
In my experience, the strongest deliveries start by asking security questions before architecture, contracts and implementation plans are locked down.
What data will we host? Where will it reside? Who needs access? How will identities be managed? What evidence will we need later? What happens when a customer is onboarded, changed or decommissioned?
For me, this is where programme management and security governance meet.
ISO 27001 provides the management-system mindset. ISO 27017 adds cloud-specific security considerations. NEN 7510 becomes particularly relevant when healthcare information is involved. ISO 9001 brings another valuable perspective: controlled, repeatable and measurable processes.
These are not just audit topics.
Used early, they help a programme make better design decisions, define responsibilities, reduce rework and create a much smoother transition into operations.
Security by design is not about slowing delivery down.
It is about preventing security from becoming the reason delivery slows down later.
#ProgramManagement #ProjectManagement #Cloud #CyberSecurity #ISO27001 #ISO27017 #NEN7510 #SecurityByDesign
Risk registers are easy to complete.
The difficult part is having the honest conversation about what can actually go wrong.
A risk register can be beautifully maintained, colour-coded and reviewed every week — and still provide very little value if people are reluctant to raise the uncomfortable issues.
The real value of risk management starts when teams feel comfortable saying:
"This could fail."
"We are not as far as we think."
"This dependency is putting the programme at risk."
"We don't have a plan B."
That is where risk management becomes more than administration.
Good risk management isn't about having a long list of risks.
It's about creating the transparency and trust to surface the risks that really matter — early enough to do something about them.
#ProjectManagement #ProgramManagement #RiskManagement #Leadership #Transformation
High-performing delivery teams do not appear by accident.
The best programme managers I know spend as much time coaching people as they do managing plans.
Because successful delivery is rarely just about timelines, milestones, budgets and status reports. It is about people — building trust, creating clarity, removing obstacles, encouraging ownership and giving teams the confidence to make decisions.
A great programme manager doesn’t just ask, “Are we on track?”
They ask:
“Does the team have what it needs to succeed?”
When people are aligned, empowered and supported, the plan becomes much easier to execute.
Strong programmes are delivered by strong teams. And strong teams are built, not managed.