Cybersecurity Is a Delivery Risk: What I Told PMI Türkiye About Digital Castles
Cybersecurity Is a Delivery Risk: What I Told PMI Türkiye About Digital Castles
On November 14, I delivered a keynote session at the 32nd Project Management Summit hosted by PMI Türkiye in Istanbul, under this year’s theme, Maximizing Project Success. My session was called “Cybersecurity: Digital Castles”.
I opened with a question I believe belongs in every project review.
Would we call a project successful if it arrives on time and on budget, but the first serious incident stops the operation?
A feature can go live and still leave the delivery fragile. If nobody has worked through the data, the access, the suppliers, and the recovery conditions, the project is not finished. It is exposed. My goal was not to turn project managers into security specialists. It was to make three things visible: who owns the risk, which decision is needed, and when that decision has to be taken.
The castle is not a wall anymore
We used to imagine security as a wall and a gate. That picture no longer matches reality. Data lives in the cloud, teams work from anywhere, and services connect to other services across companies. The modern digital castle is not static. It is an ecosystem that senses risk, limits the damage, and gets the service standing again.
That is why resilience cannot belong to the security team alone. It is shaped by project decisions, taken months before any incident.
Three myths still get in the way:
- “We are not a target.” Every organisation holds something of value, or a path to someone who does: data, access, or a trusted connection.
- “IT will handle it.” Security is a shared responsibility between technical teams and the business. Neither side can carry it alone.
- “Security slows us down.” Early security decisions reduce late surprises. What slows a project down is discovering the problem at go live.
The perimeter is gone, so identity is the project
Being inside the office network is no longer proof of safety. Employees, devices, cloud applications, and partners join the same workflow from different places. So the useful questions are different now. Who is accessing this? What exactly can they reach? Do they need it for this work? And if that access changes, would we notice?
Identity is the key to the digital castle, and it is also where projects quietly create risk. Multi factor authentication should not be treated as a technical setting that somebody in IT will get to eventually. It belongs in the work itself: which accounts will access the system, who approves them, when privileges get reviewed, and who closes the gaps. In project language, MFA is an acceptance condition, not an afterthought.
Three cases, three lessons
I used three well known cases in the session, and I want to keep the lessons precise, because these stories are often told with more drama than accuracy.
Change Healthcare. After the attack, affected systems were shut down and the disruption spread widely across the United States healthcare ecosystem. The lesson for project managers is not to hunt for one person’s mistake. It is that a single critical provider can become a dependency for an entire sector. Project plans usually map the direct supplier. They rarely map the processes, sub suppliers, and manual fallback flows connected to it. So ask the harder questions: what are our critical service dependencies, how well do our alternative or manual flows actually work, and who approved our recovery targets? Recovery time and recovery point objectives should be set by the technical team and the business owner together, then tested against realistic scenarios.
The Snowflake campaign. Mandiant reported that the campaign used customer credentials stolen earlier, and that some of the accounts examined did not have MFA enabled. Mandiant wrote that it notified around 165 organisations that were potentially exposed. Potentially exposed is not the same as breached, and the distinction matters. The lesson stands either way: choosing a cloud provider does not transfer your responsibility for your own accounts and access. The castle gate was not battered down. A key was used.
SolarWinds. This supply chain incident began in 2020, and I present it as a teaching case, not a current event. Malicious code was inserted into a legitimate software update process, which showed that even a trusted distribution mechanism carries risk. Brand recognition is not assurance. When we buy a product, we should look beyond the feature list to how it is built, distributed, and updated, who can access what, how we get notified in an incident, and how we would limit or exit the service if something went wrong.
Different stories, same pattern. Projects concentrate risk while they create value: they centralise sensitive data, build new integrations, and hand access to suppliers. Those concentration points need to be visible in the very first planning meeting, not discovered in the incident review.
Cybersecurity is the fourth side of the project
Every project manager manages scope, schedule, and cost. I argue security belongs in that same conversation, alongside dependencies and acceptance criteria. Delivering a project without security does not protect its business value, it leaves that value fragile.
This does not mean adding unlimited controls to every project. It means deciding the security conditions early, proportionate to the business impact and the organisation’s risk tolerance, and recording them properly. A cyber risk register should read like a decision register. Each entry needs more than a likelihood and an impact score. It needs an owner, a mitigation step, a deadline, a trigger, and the person authorised to accept the risk that remains. Undecided risk does not disappear. It just becomes invisible.
The same discipline applies to suppliers. Vendor assessment is not a checklist you complete at purchase and file away. Services change, sub suppliers change, access scopes drift, and threats move. Contracts, audit rights, incident notification times, update responsibilities, and exit plans belong in one conversation, with procurement, legal, security, and the business owner looking at the same decision.
A castle built in layers
When I say digital castle, I do not mean one wall, one product, or one team. I mean layers that work together: identity, data, suppliers, monitoring, response, and recovery. No single control is enough. An incident has to be detected, contained, and recovered from, and the critical business service has to come back. This is a shared map for teams to talk about roles and gaps, not a product list.
In practice, that means planning security from day one. At initiation, define the data and the business impact. In design, talk about access and threats. In procurement, ask for assurance. In testing, verify the requirements. At go live, prepare monitoring and rollback. In operation, keep reviewing access and change. Security work belongs inside every sprint, not stacked at the end as a final gate that everyone resents and nobody has time for.
I gave the room five questions to take into their next project meeting:
- What is our critical data and our critical process?
- Who are our external dependencies?
- How are identities and privileges protected?
- If the service stops, what is the alternative flow?
- Which security and recovery conditions must the project meet before we accept it?
The project manager does not have to produce those answers alone. The job is to make sure each answer has an owner, a date, and someone with the authority to decide.
When the outage day comes
The first hour of a serious outage is not the time to invent roles. Decision rights, technical contacts, alternative workflows, and stakeholder communication need to be agreed in advance. In a crisis there are two parallel tracks. The technical team investigates, isolates, and manages a safe recovery. The project manager coordinates dependencies, decision records, business continuity, and communication. Neither track works without the other, and they need regular points where they meet.
In the session we ran a 90 second tabletop exercise: a critical supplier portal is down and a sensitive data leak is being reported. I asked for the first three decisions. Who steps in? How does the critical work continue? Who tells what to whom? There is no single correct answer. The value is in having discussed roles, dependencies, and decision thresholds before the real day forces the conversation.
A 30, 60, 90 day plan
I closed with a plan that any project team can start without a certification programme or a big budget.
- In the first 30 days, inventory your critical data, processes, and dependencies.
- By 60 days, build the supplier questions, the security acceptance conditions, and clear risk ownership into your normal project routines.
- By 90 days, rehearse an outage scenario, and feed what you learn back into your plans and contracts.
And if that sounds like a lot, start tomorrow morning with just three things. In your next meeting, ask about one critical dependency. Verify MFA and access ownership on your critical accounts. Check one supplier’s incident notification and exit conditions. Pick one small, visible step with a named owner, and put it in the calendar. That is how intention becomes change in a project.
Thank you
Thank you to PMI Türkiye, the organising team, and every project professional who joined the session in Istanbul and shared their own experiences afterwards. The conversations after a talk are usually where the real learning happens, and this summit was no exception.
I finished the session with the line I will finish this post with.
Walls alone do not protect us. The right decisions we take together do.
Facts and sources checked in the speaker notes, for the record: Change Healthcare operational impact, U.S. Congressional Research Service IN12330. Snowflake campaign, stolen credentials and potential exposure notifications, Mandiant and Google Cloud Threat Intelligence, UNC5537. SolarWinds Orion supply chain incident, CISA Advisory AA20-352A. Secure development lifecycle framing, NIST Secure Software Development Framework, and CISA Secure by Design.
About Author
