sovereign cloud migration — steering

Person #35: Yalla, can you hear me? Testing, testing. I can see everyone on the list. Your Excellency, good morning. Undersecretary's office joined? I think I see them. Okay, good morning everyone. Person #34: Good morning. Let's start. We have a full agenda today. Everyone has the deck? The one I circulated yesterday at four? If not, kindly pull it up now. We'll go through the sovereign cloud migration status, the wave three slippage, and then we need to align on the messaging for the ADEC scorecard submission due next week. Person #35: Yeah, I have it. And just to be clear, wave three is not slipped. Wave three has been *resequenced*. There's a difference. We are not behind. We changed the order of operations to de-risk the go-live. That's a proactive decision, not a delay. I want that language in the minutes. Person #34: Okay, we'll get to that. But first, let's get everyone on the same page on where we are. Habibti, can you give us the two-minute overview of the migration waves? The high-level. Person #37: Sure, Your Excellency. So, wave one, that's the pilot with the three entities — the Department of Transport, ADNOC's non-OPCO entities, and the Abu Dhabi Media Office — that completed on schedule, end of May. All workloads live on the sovereign cloud. Uptime has been solid, 99.98% since cutover. Person #35: 99.98, yeah. We had one blip in the first week, but that was a network config issue on the entity side, not the platform. They didn't follow the runbook. We fixed it. Person #37: Correct. Wave two, that's the larger cohort of twelve entities, including the Department of Education and Knowledge, the Department of Municipalities and Transport, and the Abu Dhabi Quality and Conformity Council. That went live in phases through July and August. We had some data migration issues with ADEK's legacy HR system, but that was resolved with a data cleansing exercise. The last entity in wave two, the Abu Dhabi Agriculture and Food Safety Authority, went live last week. Wednesday. Person #41: Yaa, and we're still validating some of the data platform feeds for ADFSA. Their statistics returns to the Statistics Centre are... they're not flowing automatically yet. We have a manual process in place for the next two weeks. It's fine, it's fine. But it's manual. I don't love manual. Person #35: And that's exactly why we resequenced wave three. Because those manual workarounds are exactly the kind of thing that blows up in your face when you're doing forty entities at once. Person #34: So wave three is the remaining... how many? Person #37: Wave three is the remaining forty entities. We had planned to do them in four cohorts of ten, starting this month, September, through December. But with the learnings from wave two, and the issue with the legacy data quality... Person #35: It's not just data quality. It's the application teams. Guys, guys. We have application teams that are still making unplanned changes to their environments. We had an incident last week — an entity's app team pushed a configuration change to their database during our change freeze. No change ticket, no CAB approval, nothing. It caused a performance degradation that our SOC picked up. We had to roll back. That's the kind of cowboy behavior that we cannot have during a migration wave. Person #34: Which entity? Person #35: I won't name them on this call, but it's in the major incident report. The point is, we need to enforce the change management discipline before we scale. So we're pushing wave three cohort one from September 7th to September 21st. A two-week slip. A resequencing. And we're using that time to run a mandatory change management compliance checkpoint with all forty entities. Person #41: Two weeks won't fix culture, ya basha. You know that. We tried the compliance checkpoint thing in 2016 with the ADDA consolidation. We sent the letters, we did the workshops, and the first time there was a production issue, everyone called their own IT guy and did whatever they wanted. It's not a process problem, it's a respect problem. They don't respect the central mandate. Person #35: Maybe. But we have the Executive Council backing now. We have the mandate letter. If an entity violates the change freeze during a migration, we can escalate. And we will. I'd rather delay two weeks and have a clean run than have a Sev-One incident on the week of the National Day. Person #36: Excuse me. On the change freeze point. What is the exposure if an entity refuses? Specifically, what happens to their data if there's an unplanned change during the cutover window? Is it corruption? Is it loss? Is it just unavailability? I need that in the risk register. Person #35: Depends on the change and the system. Worst case, we have to re-run the data migration, which is a forty-eight hour effort. We don't anticipate data loss. But there is a corruption risk for some of the older Oracle databases. We have backups, obviously. RTO is four hours, RPO is fifteen minutes. But a re-migration is a schedule hit. Person #36: And what is the blast radius if it happens during a cutover, not during a normal operation? Person #35: During a cutover, it's contained to that entity. We've designed the waves so each entity's migration is isolated. No shared blast radius. That was the whole point of the resequencing, actually. We moved to a per-entity cutover plan rather than a cohort-wide cutover. So if one entity has a problem, the other nine in the cohort are unaffected. Person #34: I think that's a good call. Per-entity cutover is how we did it in Dubai for the Smart Government migration. We learned that lesson the hard way. The first wave, we tried to do a big bang across five entities and it was a disaster. We had to roll back two of them. After that, we went sequential. It costs more in terms of overall timeline, but the risk profile is much better. Person #41: Yaa, but it also costs more in terms of resource. Your team is going to be doing forty cutovers one by one? That's forty weekend shifts. My data platform team is already stretched thin. We're supporting the analytics backlog, we're building the new data lake for the AI use cases, and we're the ones doing the data migration validation for every wave. We can't do forty individual cutovers. Person #35: We're not asking your team to do the cutover. The cutover is an infrastructure and platform function. Your team does the data validation after the fact. And we can parallelize — we can run two cutovers per weekend. So it's twenty weekends, not forty. We're looking at finishing wave three by end of March instead of end of December. That's the cost. But it's a three-month slip that we can absorb in the overall program timeline. Person #34: Hold on. A three-month slip means we're going into the first quarter of next year. That has budget implications. The Department of Finance is not going to release the remaining tranche of the cloud budget if we haven't hit the milestone they set. It was in the budget letter... in July. "Cloud migration completion by December 31st" — I think that's the exact language. Saadat, am I wrong? Person #21: No, Your Excellency, you're not wrong. The budget circular from the Department of Finance, dated July 14th, states that the remaining 40% of the cloud infrastructure budget is contingent on "satisfactory progress against the approved milestones, including the completion of the migration of all eligible government entities' workloads to the sovereign cloud by December 31st, 2026." That's the language. Clause 4.2. So a slip to March would trigger a re-negotiation of the budget release schedule. Person #35: Okay, so we have a conflict between the risk management approach and the budget milestone. That's a conversation we need to have with the Department of Finance. Can we propose a revised milestone? Like, "completion of the first two cohorts of wave three by December 31st, with the remaining cohorts in Q1"? That gives them something concrete, and we're not overcommitting to a risky timeline. Person #34: It's not just the Department of Finance. It's the ADEC scorecard. The Digital Strategy has a KPI on cloud migration. It's one of the headline numbers. "70% of government workloads on the sovereign cloud by end of 2026." If we slip to March, that number is going to be something like 55% or 60%. And the Chairman is going to stand up at the Executive Council and have to explain why we're below the target. Person #37: We can counter with the AI use cases. The number of AI use cases that are now running on the sovereign cloud is a positive story. If we frame it as "we prioritized the enablement of AI workloads, which required a more careful migration approach," that's a narrative that lands. Person #34: It lands with people who understand technology. The Executive Council is not full of technologists. They want to see the numbers move. "70% by end of 2026" — if we say "we're at 58% and we'll get to 100% by March," the story is "we're behind." If we say "we've enabled 85 AI use cases and we're on track for 200 by 2027," the story is "we're leading." I know which one I'd rather present. Person #35: Fine. So we manage the narrative. We present the AI story as the headline, and the cloud migration as the enabling infrastructure. I can have the numbers ready by Thursday. We need to be careful, though, not to overpromise on the AI use cases. Some of those are pilot-stage. My team is running the infrastructure for the G42 partnership, and there are some compute constraints we're still working through. Person #41: What compute constraints? You've got the new GPU cluster from the G42 deal, right? That was supposed to be ready in June. Person #35: The cluster is ready. The cooling is not. We have a thermal issue in the data center. The new GPUs run hot, and the existing cooling infrastructure is not sufficient for a full load. We're running at 60% capacity until we complete the cooling upgrade. It's scheduled for... November? We have a window. Person #41: November? Yaaa, that's a problem. The AI teams are already complaining about not getting enough compute. I've had three escalations from the Calidus folks and two from the MBZUAI researchers. They want more GPU hours. If we're at 60% capacity, that's a bottleneck. Person #36: And it's a security concern. If we're running hardware at the edge of its thermal envelope, we increase the risk of hardware failure. A GPU failure during a training run is not just a compute loss — it's a potential data integrity issue if the training data wasn't checkpointed properly. I want to know who owns the risk for the compute capacity constraints. Person #35: We own it. It's our data center. We're working on it. The cooling upgrade is approved, the vendor is on site, and we have a timeline. It's a manageable risk. Not ideal, but manageable. Person #34: Okay. Let's move on. We need to talk about the TAMM 4.0 rollout. There was an incident over the weekend. I saw the reports this morning. Can someone brief us? Person #37: Yes, Your Excellency. Over the weekend, from Saturday 2:00 AM to Sunday 6:00 AM, the TAMM 4.0 portal experienced intermittent availability issues. The AI assistant was returning hallucinated fee amounts for some government service transactions. We had reports from users on social media, and the national newspapers have picked up on it. There's an article in The National this morning. Person #35: Right. And that's exactly the kind of thing that becomes a political issue. TAMM is the face of the government. If the AI assistant is telling people that their traffic fine is three times what it actually is, that's a headline. Person #34: What was the root cause? Person #37: We've identified it. It's not the AI model itself. It's a data synchronization issue between the new TAMM 4.0 backend and the legacy service catalog. The fee data was not migrated correctly in the new schema. So the AI assistant was querying an incomplete dataset for some services. It was returning, in some cases, fees from the old structure, which are outdated. Person #41: That's a data quality issue, not an AI issue. Yaani, the AI is fine. The data feed is wrong. We've been saying this for months — you can't have an AI assistant without a proper data governance layer. You need a single source of truth for service fees, and you need to validate that the AI is only pulling from that source. Person #37: We agree. The fix is underway. We have a team working on re-syncing the data and we're adding a validation layer. The AI assistant will be back online with the correct data by end of day today. We also have a communication plan — we're issuing a correction statement in coordination with the media office. Person #34: End of day is not soon enough. The markets are open. The government is open. People are calling the service centers asking about fees. We need to get ahead of this. Can we issue an interim statement before noon? Just to say "we are aware of a technical issue with the AI assistant, we are working on it, please refer to the standard service catalog for fee information. Person #37: We can have that draft ready in thirty minutes. I'll coordinate with the communications team. Person #35: And we need to talk about whether we should have a feature flag to kill the AI assistant if this happens again. That's a lesson from the banking world — you always have a kill switch for anything customer-facing. We should have a process where the AI assistant can be rolled back to manual search in under five minutes. Person #36: Agreed. And it should be a documented procedure with a drill. We should test the rollback process next week. I don't want to be in a situation where we know how to fix it but we don't know how to turn it off. Person #34: Good. Make it happen. Now, the other item — the World Governments Summit. We have our involvement in the February summit. The Chairman has been asked to speak on "AI-Native Government" and we need to prepare the talking points. Does anyone have the draft from the strategy team? Person #35: I saw a draft last week. It was thin. It was mostly about the vision and not enough about the results. If we're going to stand on a global stage and say "we're building an AI-native government," we need numbers. We need to show that we've moved from pilot to scale. The TAMM 4.0 AI assistant, the Copilot rollout to 35,000 civil servants, the sovereign cloud, the data platform — we need a coherent story. Person #34: I agree. The talking points need to be more concrete. I want to see the draft revised by Thursday. I'll ask the strategy team to work with the technology teams to get the numbers. And we need to be careful about what we claim. No exaggerations. If we say "35,000 civil servants have Copilot," we need to be able to back it up. How many have actually adopted it? Person #37: We're at about 12,000 active users per week. The rollout is technically done — all 35,000 have been provisioned with licenses. But adoption is not at the level we'd like. Some entities have been resistant. They see it as a way to reduce headcount, so they're cautious. Person #41: And there's a hardware issue. A lot of the civil servants have old laptops. Copilot is cloud-based, but the experience is much better on newer devices. If you're on a five-year-old laptop with 8GB of RAM, the experience is laggy. We need a device refresh program. But that's a procurement conversation. Person #21: It is indeed. And under the current procurement standards, a device refresh for 35,000 users would need to go through the Government Procurement Gate. We have a framework agreement with three vendors for end-user devices, but the pricing is based on a 2024 agreement. We're in the process of renegotiating for 2027. There might be an opportunity to bundle the refresh with the next agreement cycle. Person #34: So we're not going to have a device refresh before the summit? Person #21: Unlikely. The procurement timeline, under the Standards, would take at minimum four to six months from the request to the award. We would need the requirement to be signed off by the entity, the budget to be allocated, and the RFP to be published. It's not something we can expedite beyond the Standard timeline. Unless there's an exemption, of course, but that would need the Undersecretary's approval. Person #35: We don't need a full refresh. We need a targeted refresh for the heavy users — the ones who are actually using Copilot daily. Maybe 5,000 devices. That's a smaller procurement, and it could be done faster. Can we explore that? Person #21: We can explore it. The threshold for a direct purchase under the Standards is, I believe, 250,000 dirhams. Anything above that requires the Gate. A 5,000-device refresh would be well above that. But there might be a way to structure it as a pilot or a proof-of-concept that qualifies for a different procurement path. I'll need to review the Standards carefully. Person #34: Do that. We need a path forward. This is not a nice-to-have; it's a matter of the government's reputation. We're telling a story about AI-native government, and if the staff are using outdated hardware, the story falls flat. Person #41: Excuse me, Your Excellency. Can I ask a question about the data platforms item? We have a separate agenda item on data platforms, but I want to raise it now because it affects the AI story. Person #34: Go ahead. Person #41: The AI use cases — the 200+ use cases — they're all dependent on data. And right now, the data platform is supporting these use cases on an ad-hoc basis. We don't have a proper data product framework. Entities are requesting data access through different channels, and we're building one-off pipelines. That's not sustainable. We need a formal framework for data products and a self-service model for the AI teams. Person #35: That's a good point. And it aligns with what we're saying about the sovereign cloud — you need a platform, not a collection of projects. If we're going to be AI-native, we need the data infrastructure to be as mature as the cloud infrastructure. Person #36: And the security implications are significant. If the AI teams are accessing data through ad-hoc pipelines, we have no visibility into what data is being used, for what purpose, and who has access. That's a governance nightmare. We need a formal data access framework, with clear roles and responsibilities. Person #41: We've been proposing this for months. We have a draft architecture for the data platform, but it's been sitting with the architecture board for review. I've been waiting for feedback for... it's been three weeks? Four? Person #37: Team, let's be fair. The architecture board is stretched. We've had three major architecture reviews in the last month — the cloud migration, the TAMM 4.0 integration, and the new HR system on ServiceNow. The data platform review is on the agenda for next week. I'll make sure it gets the attention it needs. Person #41: Next week is fine. But I want a decision. We can't keep kicking the can down the road. The AI teams are waiting, and they're going to start building their own solutions if we don't give them a platform. And that's how we get shadow IT, and that's how we get security incidents. Person #35: Agreed. Let's put a deadline on the architecture decision. Two weeks. If the board doesn't decide, I'll make the decision myself. I'm tired of the analysis paralysis. Person #34: We'll hold you to that. Now, can we come back to the cloud migration? I want to understand the resourcing. We have forty entities in wave three. We're talking about per-entity cutovers. Who's going to do the work? The infrastructure team is... how many people? Person #35: The core infrastructure team is twelve people. Plus, we have the vendor support — the Indian vendor has twenty engineers on site, and the Oracle team has another eight. So we have about forty people available for the migration work. It's not a constraint on headcount; it's a constraint on coordination. We need to manage the dependencies between the entities — some of them share systems, and we can't cut over one without the other. Person #41: Which ones share systems? That's a big risk. If two entities are on the same legacy platform, and we cut over one but not the other, we have a split-brain scenario. The data gets out of sync. Person #35: We've mapped those dependencies. There are four clusters of entities that share systems. We're treating those clusters as single units — we cut over all entities in the cluster at the same time. That reduces the number of independent cutover events from forty to, say, thirty-two. Still a lot, but more manageable. Person #36: And what about the security testing? For each cutover, do we do a penetration test on the new environment before it goes live? Person #35: We do a vulnerability scan, not a full pen test. A full pen test for forty entities would take months. We have a baseline security standard that all new environments must meet before they're accepted. We test against that baseline. Person #36: I'm not comfortable with that. A vulnerability scan catches known vulnerabilities. It doesn't test for logic flaws, misconfigurations, or business logic issues. For a migration of this scale, I want at least a targeted pen test for the high-risk entities. The ones that handle sensitive data — health, finance, justice. Person #35: And how long would that take? Person #36: For a targeted pen test on a single entity's environment, three to five days. If we prioritize the high-risk entities, maybe we can do it in parallel. But it would add, realistically, two to three weeks to the overall timeline. Person #34: Two to three weeks. That puts us even further behind. We're already talking about March. If we add pen testing, we're looking at April, maybe May. Is that a trade-off we're willing to make? Person #35: The security risk is real. I've seen what happens when you migrate systems without proper testing. We had an incident at Emirates NBD — a migration went through without a pen test, and we found a critical vulnerability in the new environment three weeks after go-live. It cost us a lot more to fix it in production than it would have to fix it in testing. Person #36: And the risk score is higher for the sovereign cloud. We're not just migrating systems — we're building a national infrastructure. If there's a breach, it's not just one entity's data at risk. It's the government's reputation. Person #34: Okay. Let me think about this. We have three conflicting constraints: the budget milestone of December 31st, the risk management approach of per-entity cutovers, and the security requirement of pen testing. We can't have all three. Something has to give. Person #37: We could propose a phased acceptance approach to the Department of Finance. We could say "we'll accept a percentage of the budget release in December, based on the number of entities migrated, and the remaining percentage in March when we complete the full migration." That would give us some flexibility without breaching the budget agreement. Person #21: That would require a formal amendment to the budget circular. The Department of Finance doesn't typically amend circulars mid-cycle. They would likely view it as a renegotiation, and they would want something in return. There might be a local content requirement attached — "if you want the budget flexibility, you need to commit to a higher local content percentage in the cloud procurement. Person #35: We can do that. The cloud procurement already has a local content requirement, and we're working with the UAE cloud providers. We can increase the percentage if it helps close the deal. Person #34: Let's have a working session with the Department of Finance. I'll ask the Undersecretary to arrange it. We need to go in with a clear proposal, not just a request for more time. We need to show what we've achieved, and what the revised timeline means for the overall program. Person #35: I'll prepare a one-page summary with the revised timeline, the risk rationale, and the security requirements. I can have it ready by tomorrow morning. Person #34: Good. Now, on the ADEC scorecard submission — we have to submit our end-of-year performance report by... what date? The 15th of September? Person #21: The 15th. The circular from the Executive Council dated August 1st states that all departments must submit their end-of-year performance reports by the 15th of September. It's a hard deadline. The Chairman's office has confirmed. Person #34: Right. So we have two weeks to pull together the numbers. I want each of you to provide your sector's key achievements and performance indicators by end of day Friday. We'll consolidate on Monday and have a draft ready for review by Wednesday the 9th. Person #41: Yaa, boss, that's a tight turnaround. The data platform numbers — we need to get the statistics from the entities. Some of them are slow to respond. We've been chasing the Statistics Centre for weeks on their data feeds. Person #34: I know. But the deadline is the deadline. If the numbers are not perfect, we submit with the best available data. We'll note the assumptions. Person #37: One more thing — the request from the Chairman's office for the slide on the World Governments Summit. They want a single slide summarizing our AI-native government story. For the Chairman to use in a meeting with the UK delegation tomorrow. We need to deliver it by end of day today. Person #34: The UK delegation? I didn't know about that. Who's leading the UK delegation? Person #37: I believe it's the Minister for the Cabinet Office — the digital transformation team. They're in Abu Dhabi for a two-day visit. The Chairman is hosting a dinner tomorrow evening. The slide is for his briefing pack. Person #35: I can have a draft slide ready in two hours. We have the template from GITEX. I'll adapt the messaging for the UK audience. Person #34: Make sure it has the numbers. The UK is ahead of us on some things, but they're struggling with their own digital government initiatives. We're not going to lecture them, but we can show what we're doing. "AI-Native Government: A Perspective from Abu Dhabi." Something like that. Person #35: I'll keep it to one slide. Five bullets max. A few graphics. The 200+ use cases, the Copilot rollout, the sovereign cloud, the TAMM 4.0 AI assistant, and the 99.98% uptime. That's the story. Person #36: And the security posture. The fact that we have a dedicated government SOC and a national cybersecurity strategy. That's a differentiator. Person #35: Good point. I'll add it. Six bullets. Person #34: Okay. So, we have several action items. Let me summarize before we move on. First, the cloud migration timeline — we're going with the per-entity cutover approach, and we're starting the conversation with the Department of Finance about the budget milestone. Second, the TAMM AI assistant issue — we need the interim statement by noon and the fix by end of day. Third, the ADEC scorecard — submissions by Friday. Fourth, the World Governments Summit talking points — revised draft by Thursday. And fifth, the Chairman's slide for the UK delegation — by end of day. Person #35: What about the data platform architecture decision? We need that resolved. I don't want to be in a situation where the AI teams are building on sand. Person #34: We'll add it to the agenda for the architecture board next week. And we'll set a decision deadline. Two weeks, as you said. If it's not decided, we escalate to the Undersecretary. Person #41: That's all I ask. I just want a decision. We can build whatever they want, but we can't build nothing. Person #34: Agreed. Now, is there anything else before we go into the closed session? The last item on the agenda is about the entity pushback on the unified HR system. Person #37, can you give us a brief update? Person #37: Yes. We have three entities — the Department of Culture and Tourism, the ADNOC group (the non-OPCO entities), and the Department of Energy — that are resisting the migration to the unified HR system on ServiceNow. They've cited concerns about data migration, about the loss of custom workflows, and about the impact on their existing HR teams. We've had several meetings, and we've explained that the unified system is a mandate from the Executive Council. But they're still pushing back. Person #35: I don't understand the resistance. The unified HR system is a no-brainer. We're consolidating, we're reducing costs, we're improving the employee experience. What's the actual objection? Person #37: It's mostly about control. HR directors at these entities are used to having their own systems and their own processes. They see the unified system as a threat to their autonomy. And they have legitimate concerns about the transition — some of their workflows are more complex than the standard, and they're worried about losing functionality. Person #34: We need to handle this carefully. We can't be seen as forcing entities to comply. But we also can't let them drag their feet. The Executive Council has set a timeline, and we need to meet it. I'll have a conversation with the Chairman and see if we can get a more explicit directive from the Council. That usually helps. Person #37: It would. If the Chairman sends a letter to the entity chairmen, it makes our job much easier. We've had success with that approach in the past. Person #41: Yaa, the Chairman's letter works. When we did the data center consolidation, we had entities that were resisting, and the Chairman's letter was the turning point. After that, the conversations were very short. Person #34: Okay. I'll raise it with the Chairman. Now, the closed session — do we have any sensitive items that need to be discussed without the full group? Person #36: I have one. It's about the vendor risk assessment. We've identified a potential issue with one of the cloud vendors. I'd prefer to discuss it in the closed session, as it involves a commercial relationship. Person #35: Is it the Indian vendor? Because I've had some concerns about their performance in the last month. Person #36: I'm not naming names in this forum. Let's take it to the closed session. Person #34: Agreed. Let's pause the main call and move to the closed session. We'll... Person #35: Before we go closed, boss, I just want to flag—we still haven't got the revised wave 4 schedule from the entity side. The 15th came and went. I need something by Wednesday or we're going to have to push the data center exit again, and we all know what that means for the budget. Person #34: Noted. We'll take that in the closed session. Everyone else—thank you for your time. The main agenda is closed. Let's move to the restricted group only. I'll ask that anyone who doesn't need to be here for the commercial discussion drop off now. Person #21: Understood, Your Excellency. I'll stay—I have the procurement file open in case you need the vendor contract details. But I can also step off if it's purely technical. Person #34: Stay, stay. You'll need to hear this anyway. Alright—who's left? Let me check. I see #35, #36, #37, #41, #21. Good. Closing the loop now. Continue. Person #36: Right. So, the vendor risk assessment. We've been running continuous monitoring on the sovereign cloud infrastructure since the last incident—the one in July, the storage node failure. The vendor's remediation plan was accepted, but I have concerns about their incident response times. Their SLA says four hours for critical. They've been hitting six, sometimes eight. And their root cause analysis... it's been thin. We're not getting the depth we need. Person #35: Which vendor are we talking about? If it's the Indian vendor, I've seen the same. Their NOC is stretched thin. They've got other customers on the same platform, and we're not the priority. I've raised it twice with their account director. He promises improvement, but nothing changes. Person #36: It's the Indian vendor. And it's not just the SLA misses. We've identified a pattern in their access logs—a number of privileged access requests that don't match the approved change tickets. We've flagged it to their security team, but the response has been... slow. It's not a breach, but it's not clean. Person #35: What's the exposure? Are we talking about data exfiltration risk, or is it more operational? Person #36: No evidence of exfiltration. But the pattern suggests either a process failure or something we don't want to rule out. We've isolated the affected systems, tightened the access controls, and we're monitoring closely. The question is whether we escalate to a formal compliance action under the standards. If we do, it goes to the Undersecretary, and it becomes a procurement issue. Person #21: Under the Standards for Government Procurement, clause 14, we have the right to demand a corrective action plan within ten business days. If they fail, we can suspend the contract. But that's a heavy hammer. It also means we have to be sure we have a replacement plan, because the sovereign cloud is mission-critical. Person #35: We don't have a replacement plan. That's the reality. We're locked into this vendor for at least another eighteen months. We can't suspend them without a fallback, and we don't have one. Person #34: So what do you recommend? We can't ignore it, but we can't act rashly. What does the risk actually look like in practice? Person #36: The risk is moderate. We've contained it. But the pattern—it keeps repeating. Every two to three weeks, there's an access request that doesn't match the change ticket. Small things. A config change here, a log review there. But it's consistent. That's why I'm concerned. It's not a one-off mistake. It's a habit. Person #37: Have you spoken to their management directly? Not the account director—the regional head? Sometimes the account director is incentivized to smooth things over. The regional head might have more teeth. Person #36: We've had two calls. The regional head assured us it's being addressed. But the pattern hasn't changed. I'm not confident they're treating us as a priority account. And that's a problem because we're their biggest government customer in the region. Person #35: Okay, what if we put them on a formal improvement plan? Not the contract suspension, but a written plan with weekly check-ins. We hold their feet to the fire. We document everything. And we start looking at alternatives—even if it's just a feasibility study—so that if we do need to move, we have options. Person #34: That sounds reasonable. But I want to be careful about the optics. We're in the middle of the sovereign cloud narrative—the Chairman is using it as a flagship in the Executive Council. Any hint of instability becomes a political problem. So whatever we do, it stays in this room until we're ready to act. Person #36: Agreed. I'll draft the improvement plan and share it with #35 for review. We'll start the weekly check-ins next week. And #21, I'll need you to confirm the contractual basis for the plan—under the Standards, I think clause 16 covers performance monitoring. Person #21: Clause 16 covers performance monitoring, yes. And clause 18 gives us the right to request additional reporting. We can use that. I'll send you the exact language by end of day. Person #35: Good. And I'll start a light-touch evaluation of alternatives. Not a full tender—just a market scan. See what's available, what the lead time would look like. Just in case. Person #34: Keep it quiet. No external conversations. The last thing we need is the vendor hearing we're looking elsewhere and getting defensive. Person #35: Understood. Quiet. Person #41: Can I ask something? On the access log pattern—is there any chance it's just their monitoring tool being misconfigured? Because I've seen that before. A tool that generates phantom alerts, and the team is just working through the queue without checking the actual change tickets. It could be a false pattern. Person #36: It's possible. We've considered that. But we've cross-referenced with our own logs. The access events are real. They're happening. The question is whether they're authorized. And on paper, they're not matching the change tickets. So either their change management process is broken, or someone is bypassing it. Either way, it needs fixing. Person #41: Fair. Just checking. Person #34: Anything else on this? No? Okay. Next closed item—the wave 4 schedule. #35, you raised it. What's the situation? Person #35: Right. So, wave 4 was supposed to go live on the 15th. We had the infrastructure ready—compute, storage, network. But the application teams—specifically the ones at the Department of Municipalities and Transport—they've had delays in their data migration. They're blaming the data quality. They say the legacy data is messier than expected, and the cleansing is taking longer. Person #41: Yaa, we tried to warn them. We've been saying since June that the data quality is a known issue. The DMT has systems that go back to 2008. They've got duplicate records, incomplete fields, no consistent naming conventions. We told them they needed to start earlier. They didn't. Person #35: Exactly. And now we're looking at a slip of at least three weeks. Which means the data center exit slips too. The contract with the current data center provider has a termination clause at the end of October. If we miss that, we're paying for another quarter of colocation. That's significant money. Person #34: How significant? Person #35: About eight million dirhams. Maybe more if we have to extend the managed services too. Person #37: Can we negotiate an earlier termination with the provider? Sometimes they're willing to prorate if we can give them a new customer. Person #35: We've asked. They're not flexible. They have a pipeline, but they don't want to lose the revenue. So they're holding firm on the clause. Person #21: Under the procurement standards, we can invoke force majeure if there's a regulatory delay. But this is an internal delay—it doesn't qualify. We'd have to negotiate a settlement, and that would set a precedent for other providers. Person #34: So we're stuck. Either we push DMT to accelerate, or we pay for the extension. Which is more realistic? Person #35: Honestly? DMT is not going to accelerate. They're already working overtime. The data quality issue is real. We could send more resources, but that costs too. And there's a risk of introducing errors if we rush. Person #41: What if we scope down wave 4? Instead of migrating all of DMT's services, we move the core ones—the ones that are ready—and leave the rest for wave 5. We free up the data center, we hit the October deadline, and we deal with the rest later. Person #35: That's an option. But the problem is DMT wants everything moved together. They've got dependencies between services. If we split, they might have to maintain a hybrid environment for months. That's operational overhead for them. Person #34: But it might be the pragmatic choice. We can't keep paying for the old data center. The Chairman won't accept that. Let me ask—if we scope down, how much of DMT is actually ready? Person #35: Maybe sixty percent. The core services—vehicle registration, licensing, inspection—those are ready. The problem is their analytics and reporting services. Those have the messy data. Person #41: And those are the ones that cause the most problems. If we move them with dirty data, we're creating issues for the analytics team downstream. I'd rather keep them back. Person #34: I'm leaning toward the scope-down. It gets us out of the data center on time, it demonstrates progress, and it gives DMT more time to clean the data. But I need to manage the optics. The Chairman has been talking about DMT as a flagship modernization story. If we announce a partial migration, it looks like a backtrack. Person #35: We don't have to announce it as partial. We can say we're taking a phased approach—which is true. We're delivering the services that are ready first, with the remaining services following in a subsequent phase. That's a positive story. It shows discipline. Person #34: I like that framing. Let's go with the phased approach. #35, you'll work with DMT to define the phased scope. I want a list of services for phase 1 and phase 2 by Thursday. And start the negotiation on the data center extension—just in case, but we shouldn't need it. Person #35: Done. I'll have my team draft the list today, review with DMT tomorrow, and have a final version by Thursday. Person #37: I can help with the DMT conversation. I have a good relationship with their chief digital officer. We worked together on the ADERP rollout. I can smooth things over. Person #34: Good. Include her in the meetings. We need DMT to feel like they're partners, not subjects. Person #41: One more thing on the data center—if we're scoping down, we have some equipment that's being decommissioned. The storage arrays from the old platform. Some of them are still under maintenance contracts. We could potentially sell them or use them for internal testing. Person #35: Let's not get ahead of ourselves. We'll deal with the decommissioning after the migration. Right now, focus on the phased scope. Person #41: Fine. Just thinking ahead. Person #34: Any other items for the closed session? No? Then let's wrap up. Before we close—#37, you mentioned the slide. Did you get the request? Person #37: Yes. The Chairman's office asked for a slide on the sovereign cloud progress—for the ADEC meeting on Thursday. They want a summary of milestones, the timeline, and the upcoming priorities. It needs to fit on one slide. They want it by end of day today. Person #35: One slide? We're supposed to summarize a two-year program on one slide? That's an exercise in brevity. Person #37: It's what they asked for. I'll draft it, but I need your numbers, #35. The uptime stats, the number of entities migrated, the compute capacity. Can you send them to me by noon? Person #35: I'll send them by 11. But let me set expectations—the uptime stats are good. Ninety-nine point nine-eight over the last quarter. The entities migrated—we're at 23 out of 53. The compute capacity—I need to check the latest figures. I'll have them to you. Person #37: Perfect. And #36, can you give me a one-liner on the security posture? Something positive but not over-promising. Person #36: Security posture remains strong, with continuous monitoring and no major incidents in the last quarter." That's as far as I'll go. Person #37: Good enough. I'll compile it and send it to the Chairman's office by 4. Person #34: Alright. Anything else? No. Let's close. Good work, everyone. I'll see you at the governance committee meeting on Thursday. Keep me posted on the DMT conversations and the improvement plan. Yalla, khalas. Person #35: Will do. Thanks, boss. Person #36: Thank you. Person #41: Take care, everyone. Person #37: Bye for now. I'll be in touch. Person #21: Good afternoon.