Power Platform Is Secure — Until Governance Disappears

1
00:00:00,000 --> 00:00:02,960
Most organizations still ask the wrong question about Power Platform.

2
00:00:02,960 --> 00:00:06,320
Is this thing secure enough for enterprise-ordered heavy use?

3
00:00:06,320 --> 00:00:09,400
They assume the risk lives in Microsoft's stack? It doesn't.

4
00:00:09,400 --> 00:00:13,360
Here's the blunt answer, yes, the Power Platform Security architecture is enterprise-grade.

5
00:00:13,360 --> 00:00:15,920
The weak link is almost never Microsoft's security.

6
00:00:15,920 --> 00:00:17,320
The weak link is your governance.

7
00:00:17,320 --> 00:00:18,400
This isn't theoretical.

8
00:00:18,400 --> 00:00:22,240
These failures are already showing up in audits, incidents, and post-mortems.

9
00:00:22,240 --> 00:00:25,480
If you're responsible for enterprise-risk compliance or platform strategy,

10
00:00:25,480 --> 00:00:27,040
this conversation is for you.

11
00:00:27,040 --> 00:00:30,840
So in this episode, you'll see why Power Platform is secure, how governance disappears

12
00:00:30,840 --> 00:00:35,080
in real tenants and what a defendable operating model actually looks like.

13
00:00:35,080 --> 00:00:36,480
Why this question exists?

14
00:00:36,480 --> 00:00:38,440
Enterprise anxiety around low-code.

15
00:00:38,440 --> 00:00:43,200
Most enterprises didn't wake up one day and decide to run critical processes on a low-code platform.

16
00:00:43,200 --> 00:00:45,480
They arrived here through a very specific path.

17
00:00:45,480 --> 00:00:50,080
Years of backlogs, shadow spreadsheets, access databases under someone's desk,

18
00:00:50,080 --> 00:00:54,400
and temporary macros that turned into business-critical systems.

19
00:00:54,400 --> 00:00:57,320
Power Platform just made that visible, fast, and tenant-wide.

20
00:00:57,320 --> 00:01:01,840
Now add the scale, Power Apps, Power Automate, Power BI, Co-Pilot Studio,

21
00:01:01,840 --> 00:01:07,760
all sitting in the same Microsoft 365 tenant as your email, your SharePoint, your Teams, your Entra ID,

22
00:01:07,760 --> 00:01:10,560
you're not experimenting with a toy platform off to the side.

23
00:01:10,560 --> 00:01:14,240
You're plugging a low-code engine straight into the center of your digital estate.

24
00:01:14,240 --> 00:01:15,840
That's where the anxiety comes from.

25
00:01:15,840 --> 00:01:18,040
On one side, you have the marketing story.

26
00:01:18,040 --> 00:01:19,440
Anyone can build.

27
00:01:19,440 --> 00:01:20,760
And to be fair, that's mostly true.

28
00:01:20,760 --> 00:01:26,400
With data-verse connectors and co-pilot, the friction to build something real is lower than it has ever been.

29
00:01:26,400 --> 00:01:28,520
On the other side, you have the audit story.

30
00:01:28,520 --> 00:01:29,640
Who owns this?

31
00:01:29,640 --> 00:01:30,840
Where does the data go?

32
00:01:30,840 --> 00:01:33,160
What happens if the person who built it leaves?

33
00:01:33,160 --> 00:01:34,680
Those are not Power Platform questions.

34
00:01:34,680 --> 00:01:36,240
Those are governance questions.

35
00:01:36,240 --> 00:01:39,320
But because the platform is visible, it becomes the scapegoat.

36
00:01:39,320 --> 00:01:42,480
Low-code feels out of control for three architectural reasons.

37
00:01:42,480 --> 00:01:43,560
First, speed.

38
00:01:43,560 --> 00:01:47,720
Traditional development forces you through demand management, design reviews, changeboards.

39
00:01:47,720 --> 00:01:49,320
Power Platform collapses that.

40
00:01:49,320 --> 00:01:53,120
A motivated analyst can go from idea to production adjacent in days.

41
00:01:53,120 --> 00:01:55,800
Your governance model probably still assumes months.

42
00:01:55,800 --> 00:01:57,480
Second, invisible change.

43
00:01:57,480 --> 00:02:01,400
Most enterprises have monitoring for servers, networks, maybe some APIs.

44
00:02:01,400 --> 00:02:03,280
They rarely have real monitoring for.

45
00:02:03,280 --> 00:02:06,760
We just added three more approval paths to this flow that touches payroll.

46
00:02:06,760 --> 00:02:10,160
Low-code change happens at the edges of your existing observability.

47
00:02:10,160 --> 00:02:13,440
Third, citizen development without citizen development governance.

48
00:02:13,440 --> 00:02:17,000
You empowered business users to build, but you didn't give them an operating model.

49
00:02:17,000 --> 00:02:22,120
No environment strategy, no DLP baseline, no racey for app ownership, no life cycle rules.

50
00:02:22,120 --> 00:02:24,280
You gave them a Ferrari and left the keys in.

51
00:02:24,280 --> 00:02:27,000
So the CIO sees adoption spikes in the admin center.

52
00:02:27,000 --> 00:02:31,000
The key source sees connectors that can technically move data to Gmail and Dropbox.

53
00:02:31,000 --> 00:02:35,760
Compliance sees Power BI reports over HR and finance data built by people they've never met.

54
00:02:35,760 --> 00:02:37,480
Everyone asks the same question.

55
00:02:37,480 --> 00:02:39,560
Is Power Platform secure enough for us?

56
00:02:39,560 --> 00:02:41,520
From their perspective, it feels reasonable.

57
00:02:41,520 --> 00:02:43,760
Breach headlines involve cloud services all the time.

58
00:02:43,760 --> 00:02:44,800
The platform is visible.

59
00:02:44,800 --> 00:02:46,000
The controls are not.

60
00:02:46,000 --> 00:02:48,520
Architecturally though, that question is misdirected.

61
00:02:48,520 --> 00:02:49,920
Power Platform sits on Azure.

62
00:02:49,920 --> 00:02:51,200
Identity is enter ID.

63
00:02:51,200 --> 00:02:54,480
Data can live in data versus in SQL in SharePoint in fabric.

64
00:02:54,480 --> 00:02:59,040
The security primitives, authentication, authorization, encryption, conditional access,

65
00:02:59,040 --> 00:03:02,080
customer managed keys, DLP auditing already exists.

66
00:03:02,080 --> 00:03:06,520
The platform team at Microsoft has a full-time job making sure those primitives meet enterprise

67
00:03:06,520 --> 00:03:08,040
and regulatory standards.

68
00:03:08,040 --> 00:03:09,440
Your job is completely different.

69
00:03:09,440 --> 00:03:14,320
Your job is to decide who can build, where they can build, what data they are allowed to touch,

70
00:03:14,320 --> 00:03:18,960
how those changes move through DevTest prod and how you'll notice when reality drifts away

71
00:03:18,960 --> 00:03:20,200
from your intent.

72
00:03:20,200 --> 00:03:24,080
That's governance and that governance expresses itself through one thing, the control plane.

73
00:03:24,080 --> 00:03:29,040
The control plane is everything that turns we want this to be safe into actual configuration.

74
00:03:29,040 --> 00:03:33,680
Environments, DLP policies, security roles, conditional access rules, environment routing,

75
00:03:33,680 --> 00:03:36,200
managed environments, COE automation.

76
00:03:36,200 --> 00:03:39,240
When that control plane is coherent, Power Platform behaves predictably.

77
00:03:39,240 --> 00:03:42,800
When it's not, you're running a distributed decision engine with no clear design.

78
00:03:42,800 --> 00:03:44,280
This is the uncomfortable truth.

79
00:03:44,280 --> 00:03:48,880
The platform is already operating at enterprise scale, whether you acknowledge it or not.

80
00:03:48,880 --> 00:03:53,000
You might still think of Power Apps as that thing the HR team uses for a form.

81
00:03:53,000 --> 00:03:57,560
In reality, it's a multi-tenant, low-code surface attached to your core identity provider.

82
00:03:57,560 --> 00:04:00,200
So when you ask, is Power Platform secure enough?

83
00:04:00,200 --> 00:04:04,280
You're really asking, can we govern enterprise, low-code and AI at the speed our users are already

84
00:04:04,280 --> 00:04:05,280
moving?

85
00:04:05,280 --> 00:04:09,600
And right now for most organizations, the honest answer is not with the governance model

86
00:04:09,600 --> 00:04:11,440
you inherited from classic IT.

87
00:04:11,440 --> 00:04:15,080
That's why we need to separate three concepts very clearly.

88
00:04:15,080 --> 00:04:20,160
Security, what Microsoft Secures, governance, how you decide the platform should be used.

89
00:04:20,160 --> 00:04:25,720
Control plane, where those decisions either become enforceable policy or slowly decay into chaos.

90
00:04:25,720 --> 00:04:28,680
To judge risk properly, you have to stop blurring those three together.

91
00:04:28,680 --> 00:04:32,480
Once you see that split, you can ask a better question, what does Microsoft actually secure

92
00:04:32,480 --> 00:04:36,360
for you and where does your governance start to fail in real tenants?

93
00:04:36,360 --> 00:04:41,160
Security versus governance versus control plane, the foundational, misunderstanding.

94
00:04:41,160 --> 00:04:45,640
Most organizations collapse three very different ideas into one vague feeling of comfort.

95
00:04:45,640 --> 00:04:48,240
And they say Microsoft is secure, so we're fine.

96
00:04:48,240 --> 00:04:50,840
Or I don't trust this platform, lock it down.

97
00:04:50,840 --> 00:04:52,960
Both positions are based on the same misunderstanding.

98
00:04:52,960 --> 00:04:56,680
They treat security, governance and the control plane as if they're the same thing.

99
00:04:56,680 --> 00:04:59,400
They're not, let's define them in architectural terms.

100
00:04:59,400 --> 00:05:02,840
Security in this context is what Microsoft implements and operates.

101
00:05:02,840 --> 00:05:05,720
Power Platform is a SAS layer on Azure and EntraID.

102
00:05:05,720 --> 00:05:09,840
That stack gives you identity, authentication, authorization, primitives, encryption at

103
00:05:09,840 --> 00:05:14,160
rest and in transit, regional isolation, customer manage keys, logging and compliance

104
00:05:14,160 --> 00:05:15,160
certifications.

105
00:05:15,160 --> 00:05:17,200
That's security.

106
00:05:17,200 --> 00:05:20,280
Governance is what you decide to do with that capability surface.

107
00:05:20,280 --> 00:05:24,840
It's your intent, expressed as policy, who can build which data sources are allowed, what

108
00:05:24,840 --> 00:05:29,440
constitutes production, what risk levels are acceptable per business unit, how you treat

109
00:05:29,440 --> 00:05:32,560
citizen development, how long solutions are supported.

110
00:05:32,560 --> 00:05:35,240
Governance is your operating model and your rules of engagement.

111
00:05:35,240 --> 00:05:39,480
The control plane is everything that turns those rules into actual behavior.

112
00:05:39,480 --> 00:05:44,320
Governance, security groups, data verse roles, DLP policies, connect or classifications, tenant

113
00:05:44,320 --> 00:05:50,040
isolation, conditional access environment routing, managed environments, QE automation,

114
00:05:50,040 --> 00:05:52,800
audit and monitoring, all of that is control plane.

115
00:05:52,800 --> 00:05:56,480
It's the distributed configuration layer that tells the platform how to behave for your

116
00:05:56,480 --> 00:05:57,480
tenant.

117
00:05:57,480 --> 00:05:59,520
Security is Microsoft's job.

118
00:05:59,520 --> 00:06:00,520
Governance is your job.

119
00:06:00,520 --> 00:06:03,240
The control plane is where those jobs meet or fail to meet.

120
00:06:03,240 --> 00:06:07,080
When people say, "Wow, power platform is secure," they're usually pointing at the first

121
00:06:07,080 --> 00:06:08,080
layer.

122
00:06:08,080 --> 00:06:11,640
When they say, "Power platform is dangerous," they're usually reacting to the second and

123
00:06:11,640 --> 00:06:14,880
third layer as being absent in consistent or opaque.

124
00:06:14,880 --> 00:06:19,160
Conflating secure platform with well-governed usage produces two predictable failure modes.

125
00:06:19,160 --> 00:06:20,520
The first is blind trust.

126
00:06:20,520 --> 00:06:24,440
You see the compliance badge is the azure branding, the enter ID integration.

127
00:06:24,440 --> 00:06:28,560
You assume that because the underlying security model is robust, whatever your user's

128
00:06:28,560 --> 00:06:30,920
build on top must inherit that robustness.

129
00:06:30,920 --> 00:06:33,840
You let the default environment run as a free for all.

130
00:06:33,840 --> 00:06:36,320
You never define a data loss prevention strategy.

131
00:06:36,320 --> 00:06:38,640
You never classify environments by data sensitivity.

132
00:06:38,640 --> 00:06:39,920
You never ask who owns what?

133
00:06:39,920 --> 00:06:42,200
You think you're safe because Microsoft is secure.

134
00:06:42,200 --> 00:06:43,200
You're not.

135
00:06:43,200 --> 00:06:46,400
You've just outsourced your assumptions to a control plane you never designed.

136
00:06:46,400 --> 00:06:48,320
The second failure mode is over lockdown.

137
00:06:48,320 --> 00:06:49,760
You're nervous about low code.

138
00:06:49,760 --> 00:06:53,200
You treat every citizen developer as a potential insider threat.

139
00:06:53,200 --> 00:06:58,360
So you ban most connectors, you block environment creation, you push all development into a single,

140
00:06:58,360 --> 00:07:02,920
IT-owned environment, and you insist that every app go through the same heavyweight process

141
00:07:02,920 --> 00:07:04,600
as a custom net system.

142
00:07:04,600 --> 00:07:07,880
You think you're reducing risk in reality, you're generating shadow IT.

143
00:07:07,880 --> 00:07:11,760
The business still needs automation, so it goes back to spreadsheets, access, unsanctioned

144
00:07:11,760 --> 00:07:14,000
SaaS, and personal cloud storage.

145
00:07:14,000 --> 00:07:18,040
You've moved risk off the power platform service and into places that are much harder

146
00:07:18,040 --> 00:07:19,040
to see.

147
00:07:19,040 --> 00:07:23,000
In both cases, the underlying security posture of the platform hasn't changed.

148
00:07:23,000 --> 00:07:27,360
What changed is how your governance intent or the lack of it was expressed in the control

149
00:07:27,360 --> 00:07:28,360
plane.

150
00:07:28,360 --> 00:07:31,400
Architecturally, power platform is not an app builder.

151
00:07:31,400 --> 00:07:36,520
It is a distributed decision engine that makes real-time authorization and data movement decisions

152
00:07:36,520 --> 00:07:39,520
based on the configuration of that control plane.

153
00:07:39,520 --> 00:07:44,680
Every DLP rule, every environment, every dataverse role, every conditional access policy is

154
00:07:44,680 --> 00:07:47,920
effectively a line of code in an invisible authorization compiler.

155
00:07:47,920 --> 00:07:51,840
When you add just one exception for a VIP, you're not making a small change.

156
00:07:51,840 --> 00:07:54,440
You're introducing a new branch into that compiler.

157
00:07:54,440 --> 00:07:58,240
When you copy an environment for quick testing and don't fix the roles, you're duplicating

158
00:07:58,240 --> 00:08:01,640
an authorization graph you already don't fully understand.

159
00:08:01,640 --> 00:08:05,380
When you let environment creation run open, you're allowing anyone to add new decision

160
00:08:05,380 --> 00:08:07,200
services you don't monitor.

161
00:08:07,200 --> 00:08:10,560
Over time, those exceptions, copies, and ad hoc decisions accumulate.

162
00:08:10,560 --> 00:08:12,280
That's architectural erosion.

163
00:08:12,280 --> 00:08:16,160
That's how you move from a deterministic security model where you can confidently predict

164
00:08:16,160 --> 00:08:20,840
behavior to a probabilistic one where you're hoping nothing surprising happens.

165
00:08:20,840 --> 00:08:23,000
This is the foundational misunderstanding.

166
00:08:23,000 --> 00:08:27,240
Power platform security and power platform governance are not the same thing, and neither

167
00:08:27,240 --> 00:08:30,000
of them is the same as the control plane.

168
00:08:30,000 --> 00:08:33,360
Security answers can this platform be operated safely at enterprise scale?

169
00:08:33,360 --> 00:08:35,400
Governance answers, how do we want to use it?

170
00:08:35,400 --> 00:08:39,000
The control plane answers what actually happens when someone in our tenant clicks run.

171
00:08:39,000 --> 00:08:42,880
So if you remember nothing else so far, Microsoft secures the platform.

172
00:08:42,880 --> 00:08:47,760
Governance secures your usage, and the control plane is where your intent either becomes policy

173
00:08:47,760 --> 00:08:49,200
or becomes chaos.

174
00:08:49,200 --> 00:08:53,680
Once you see that clearly, the next logical question isn't, is power platform secure?

175
00:08:53,680 --> 00:08:56,000
It's, what does Microsoft actually secure for us?

176
00:08:56,000 --> 00:08:59,320
And where does our governance start to disappear in real tenants?

177
00:08:59,320 --> 00:09:01,600
What Microsoft actually secures?

178
00:09:01,600 --> 00:09:03,680
Identity, data, compliance.

179
00:09:03,680 --> 00:09:07,240
So let's answer the fair question, what does Microsoft actually secure for you in power

180
00:09:07,240 --> 00:09:08,240
platform?

181
00:09:08,240 --> 00:09:09,600
Start with identity and access.

182
00:09:09,600 --> 00:09:13,960
Every sign into power apps, power automate, power BI, co-pilot studio, all of that runs

183
00:09:13,960 --> 00:09:15,560
through Microsoft and 3ID.

184
00:09:15,560 --> 00:09:19,720
That means a single identity plane for humans and non-human identities.

185
00:09:19,720 --> 00:09:24,880
Users, service principles, managed identities, even AI agents as those mature.

186
00:09:24,880 --> 00:09:27,440
The platform itself doesn't invent a new identity store.

187
00:09:27,440 --> 00:09:29,160
It consumes your existing one.

188
00:09:29,160 --> 00:09:34,200
So when you turn on multi-factor authentication, when you enforce conditional access policies

189
00:09:34,200 --> 00:09:39,760
for risky locations or unmanaged devices, when you require compliant machines for admins,

190
00:09:39,760 --> 00:09:43,160
those controls apply to the power platform service as well.

191
00:09:43,160 --> 00:09:45,240
You're operating a single unified front door.

192
00:09:45,240 --> 00:09:49,320
On top of that, environment access is mediated through security groups and roles.

193
00:09:49,320 --> 00:09:52,000
A user can't just appear in a restricted environment.

194
00:09:52,000 --> 00:09:56,080
They have to be granted a role in that environment or be in a group you chose.

195
00:09:56,080 --> 00:10:00,060
Dataverse then adds another layer, table level, row level and field level security via security

196
00:10:00,060 --> 00:10:03,320
roles and if you choose hierarchy security.

197
00:10:03,320 --> 00:10:05,280
Architecturally identity is not the weak point.

198
00:10:05,280 --> 00:10:08,860
As long as you've treated enter ID as an enterprise control plane and not as a glorified

199
00:10:08,860 --> 00:10:09,860
address book.

200
00:10:09,860 --> 00:10:12,040
Now the data plane.

201
00:10:12,040 --> 00:10:13,040
Dataverse.

202
00:10:13,040 --> 00:10:17,160
The relational data platform behind model-driven apps and many serious canvas apps runs

203
00:10:17,160 --> 00:10:18,960
as a managed service on Azure.

204
00:10:18,960 --> 00:10:20,640
Data is encrypted at rest and in transit.

205
00:10:20,640 --> 00:10:24,880
You can bring customer-managed keys in managed environments if your regulatory model demands

206
00:10:24,880 --> 00:10:25,880
it.

207
00:10:25,880 --> 00:10:27,000
There's regional isolation.

208
00:10:27,000 --> 00:10:30,960
Your Europe data doesn't quietly drift to the US because someone felt like it.

209
00:10:30,960 --> 00:10:32,640
Environment boundaries are real.

210
00:10:32,640 --> 00:10:36,160
A dataverse environment is a security and data boundary.

211
00:10:36,160 --> 00:10:39,520
Records don't casually flow between environments unless you build something to do that.

212
00:10:39,520 --> 00:10:41,480
Back up and restore capabilities exist.

213
00:10:41,480 --> 00:10:44,640
There's auditing at the table and field level if you enable it.

214
00:10:44,640 --> 00:10:48,640
The data platform side of power platform behaves like an enterprise service because that's

215
00:10:48,640 --> 00:10:50,160
exactly what it is.

216
00:10:50,160 --> 00:10:53,640
Even when you're not using dataverse where maybe you're building over SQL, SharePoint,

217
00:10:53,640 --> 00:10:57,920
Fabric or external systems, power platform doesn't bypass those security models.

218
00:10:57,920 --> 00:11:02,240
It connects with your identity, respects the underlying permissions and relies on the

219
00:11:02,240 --> 00:11:05,160
connectors and DLP policies to control data movement.

220
00:11:05,160 --> 00:11:07,480
That brings us to guardrails, data loss prevention.

221
00:11:07,480 --> 00:11:11,760
From the admin center you classify connectors into groups, business, non-business and blocked.

222
00:11:11,760 --> 00:11:15,240
In the newer model, allowed and blocked, those policies can be ten and wide or scope

223
00:11:15,240 --> 00:11:16,760
to specific environments.

224
00:11:16,760 --> 00:11:18,840
The rules are simple but powerful.

225
00:11:18,840 --> 00:11:22,800
Most connectors can't be combined with non-business ones in the same app or flow and blocked

226
00:11:22,800 --> 00:11:24,560
connectors can't be used at all.

227
00:11:24,560 --> 00:11:29,800
For example, you can allow SharePoint, Dataverse and Exchange in a finance prod policy and block

228
00:11:29,800 --> 00:11:32,120
things like Twitter, Dropbox and Personal One Drive.

229
00:11:32,120 --> 00:11:36,480
You can use tenant isolation to say, flows in this tenant cannot send data to tenants we

230
00:11:36,480 --> 00:11:37,480
don't trust.

231
00:11:37,480 --> 00:11:42,400
You can apply more permissive policies in dev and far stricter ones in prod.

232
00:11:42,400 --> 00:11:45,080
Those DLP policies are not theoretical paper statements.

233
00:11:45,080 --> 00:11:49,160
They are enforced by the platform's decision engine at design time and at run time.

234
00:11:49,160 --> 00:11:53,800
When a maker tries to build across a boundary, you declare invalid, the platform stops them.

235
00:11:53,800 --> 00:11:57,800
Finally, compliance.

236
00:11:57,800 --> 00:12:01,920
Power platform inherits Microsoft's broader compliance stack.

237
00:12:01,920 --> 00:12:08,040
Certifications like ISO, SOC, GDPR alignment, HIPAA support, region-specific obligations.

238
00:12:08,040 --> 00:12:12,400
It integrates with Microsoft purview for auditing, so admin, maker and user actions around

239
00:12:12,400 --> 00:12:15,960
apps and flows can be locked and searched in the same compliance portal as your exchange

240
00:12:15,960 --> 00:12:17,880
and SharePoint events.

241
00:12:17,880 --> 00:12:22,560
Dataverse auditing lets you see who changed which field, when and from what to what.

242
00:12:22,560 --> 00:12:27,400
Power automate and power apps events can be surfaced through Microsoft 365 audit logs.

243
00:12:27,400 --> 00:12:32,280
With managed environments and the newer security hub, you also get a security score, a qualitative

244
00:12:32,280 --> 00:12:35,200
view of whether you've actually turned on the controls that exist.

245
00:12:35,200 --> 00:12:37,640
From a platform perspective, this matters.

246
00:12:37,640 --> 00:12:40,160
Identity is centralized and strongly authenticated.

247
00:12:40,160 --> 00:12:44,240
Data addressed and in transit is encrypted with enterprise options for key management.

248
00:12:44,240 --> 00:12:47,800
Guardrails like DLP and tenant isolation exist in our enforced.

249
00:12:47,800 --> 00:12:49,520
Compliance hooks and audit logs are there.

250
00:12:49,520 --> 00:12:53,920
If you're looking for the easy story where a power platform is insecure, you won't find

251
00:12:53,920 --> 00:12:55,880
it in the core architecture.

252
00:12:55,880 --> 00:12:58,480
Enterprise low-code platform security is not the weak link.

253
00:12:58,480 --> 00:13:03,120
The weak link is what you choose to do or not do with the control plane that sits on top

254
00:13:03,120 --> 00:13:04,120
of it.

255
00:13:04,120 --> 00:13:07,400
So if the foundation is this strong, the obvious question becomes, where do things actually

256
00:13:07,400 --> 00:13:08,800
break in production tenants?

257
00:13:08,800 --> 00:13:09,960
They don't break in a zooer.

258
00:13:09,960 --> 00:13:14,640
They break when governance disappears on where security breaks when governance disappears.

259
00:13:14,640 --> 00:13:18,920
If the platform is this strong, why do real tenants still end up with data exfiltration,

260
00:13:18,920 --> 00:13:21,600
audit failures and apps nobody can support?

261
00:13:21,600 --> 00:13:24,640
Because security almost never fails at the cryptography layer.

262
00:13:24,640 --> 00:13:26,160
It fails at the governance layer.

263
00:13:26,160 --> 00:13:29,600
There are three structural failure points that show up in almost every enterprise power

264
00:13:29,600 --> 00:13:30,680
platform review.

265
00:13:30,680 --> 00:13:33,080
The first is the open default environment.

266
00:13:33,080 --> 00:13:35,440
By design, every tenant gets a default environment.

267
00:13:35,440 --> 00:13:40,480
If you've done nothing, every licensed user is effectively an environment maker there.

268
00:13:40,480 --> 00:13:44,720
That means anyone can build apps and flows, connect to whatever your DLP allows and share

269
00:13:44,720 --> 00:13:46,200
with anyone in the tenant.

270
00:13:46,200 --> 00:13:51,160
If you never repurpose that default environment, never constrained it to personal productivity,

271
00:13:51,160 --> 00:13:56,600
never put a tight DLP policy around it, never turned on, monitoring, you've basically created

272
00:13:56,600 --> 00:13:59,800
a global sandbox directly attached to your production data.

273
00:13:59,800 --> 00:14:01,160
People don't do this maliciously.

274
00:14:01,160 --> 00:14:03,400
They just press create where the button appears.

275
00:14:03,400 --> 00:14:07,880
And from an architectural perspective, an ungoverned default environment is an entropy generator.

276
00:14:07,880 --> 00:14:11,600
It's constantly producing new assets that don't map to any operating model.

277
00:14:11,600 --> 00:14:14,920
The second failure point is free for all environment creation.

278
00:14:14,920 --> 00:14:19,240
If anyone or any broad admin group can create environments on demand, you get a different

279
00:14:19,240 --> 00:14:20,840
flavor of chaos.

280
00:14:20,840 --> 00:14:24,040
Project teams spin up a new environment just for this initiative.

281
00:14:24,040 --> 00:14:27,320
Consultants create environments for POCs and never clean them up.

282
00:14:27,320 --> 00:14:30,840
Regional teams create copies of production with slightly tweaked names.

283
00:14:30,840 --> 00:14:33,840
Each of those environments is a new control plane surface.

284
00:14:33,840 --> 00:14:38,440
Its own DLP scope, its own security roles, its own connectors, its own database.

285
00:14:38,440 --> 00:14:41,960
If you don't have a platform team curating those, you end up with dozens or hundreds of

286
00:14:41,960 --> 00:14:45,640
environments whose purpose, owner and risk level are unclear.

287
00:14:45,640 --> 00:14:50,120
At that point, no amount of enter ID or AS256 saves you.

288
00:14:50,120 --> 00:14:52,080
You're running a fleet you don't understand.

289
00:14:52,080 --> 00:14:55,920
The third failure point is the absence of a coherent data loss prevention strategy.

290
00:14:55,920 --> 00:14:58,000
You technically have DLP policies.

291
00:14:58,000 --> 00:15:01,960
Some created test DLP one during a pilot two years ago.

292
00:15:01,960 --> 00:15:04,440
Another admin copied it and tweaked a connector.

293
00:15:04,440 --> 00:15:08,440
A consultant added an environment level policy for a specific project.

294
00:15:08,440 --> 00:15:12,900
Over time you've accumulated a stack of overlapping inconsistent policies whose intent no one

295
00:15:12,900 --> 00:15:13,900
can explain.

296
00:15:13,900 --> 00:15:15,400
In some environments Gmail is blocked.

297
00:15:15,400 --> 00:15:18,840
In others it's quietly allowed because nobody added the policy there.

298
00:15:18,840 --> 00:15:21,640
In dev, HTTP connectors are wide open.

299
00:15:21,640 --> 00:15:24,600
Improved they're blocked but nobody ever tested the migration path.

300
00:15:24,600 --> 00:15:28,920
The default environment sits under a tenant wide policy that looked reasonable before copilot

301
00:15:28,920 --> 00:15:30,480
started generating apps.

302
00:15:30,480 --> 00:15:33,200
This is where architectural erosion becomes visible.

303
00:15:33,200 --> 00:15:36,680
Every exception, bypass and temporary override becomes security dead.

304
00:15:36,680 --> 00:15:39,240
I'll just add Outlook.com to business connectors for now.

305
00:15:39,240 --> 00:15:40,960
We'll remove it after the demo.

306
00:15:40,960 --> 00:15:44,800
We'll clone production into this uncopy environment so the vendor can test.

307
00:15:44,800 --> 00:15:46,360
We'll delete it later.

308
00:15:46,360 --> 00:15:49,480
We'll disable this DLP policy because it's blocking an important flow.

309
00:15:49,480 --> 00:15:50,880
We'll fix it next sprint.

310
00:15:50,880 --> 00:15:54,040
Those next sprints rarely arrive at the exceptions stay.

311
00:15:54,040 --> 00:15:55,400
New ones accumulate.

312
00:15:55,400 --> 00:15:58,600
Your control plane drifts further away from your governance intent.

313
00:15:58,600 --> 00:16:00,640
At small scale you can still reason about it.

314
00:16:00,640 --> 00:16:04,760
At enterprise scale, thousands of makers, tens of thousands of apps and flows across dozens

315
00:16:04,760 --> 00:16:07,800
of environments are no longer in a deterministic security model.

316
00:16:07,800 --> 00:16:09,520
You're in probabilistic territory.

317
00:16:09,520 --> 00:16:13,240
You've moved from we know exactly what's allowed to we think this combination is probably

318
00:16:13,240 --> 00:16:14,240
safe.

319
00:16:14,240 --> 00:16:15,760
That's what I mean by conditional chaos.

320
00:16:15,760 --> 00:16:17,600
On paper you're a zero-trust shop.

321
00:16:17,600 --> 00:16:18,880
You verify explicitly.

322
00:16:18,880 --> 00:16:20,240
You use least privilege.

323
00:16:20,240 --> 00:16:21,320
You assume breach.

324
00:16:21,320 --> 00:16:23,800
In practice, your conditional access rules.

325
00:16:23,800 --> 00:16:27,880
Your DLP policies, your environment roles and your special case environments have grown

326
00:16:27,880 --> 00:16:28,880
organically.

327
00:16:28,880 --> 00:16:34,760
Nobody has an end-to-end map of how a given identity, on a given device in a given location,

328
00:16:34,760 --> 00:16:37,400
interacting with a given app will actually be treated.

329
00:16:37,400 --> 00:16:41,920
At that point, blaming power platform security is convenient but inaccurate.

330
00:16:41,920 --> 00:16:46,200
Most of the risks you'll see at scale, data exfiltration through connectors, shadow IT flows

331
00:16:46,200 --> 00:16:51,800
over regulated data, apps with no clear owner, business critical logic wired through a personal

332
00:16:51,800 --> 00:16:57,520
account are governance failures, masquerading as platform issues.

333
00:16:57,520 --> 00:17:01,000
Power platform shadow IT isn't people sneaking in a new SaaS product.

334
00:17:01,000 --> 00:17:04,520
It's people doing exactly what the platform allows in the absence of guardrails and once

335
00:17:04,520 --> 00:17:09,200
co-pilot and a genetic AI enter that already weak governance model, the risk doesn't just

336
00:17:09,200 --> 00:17:10,200
increase linearly.

337
00:17:10,200 --> 00:17:14,200
It multiplies because now the platform can generate apps and flows faster than your existing

338
00:17:14,200 --> 00:17:16,520
manual controls can classify or review them.

339
00:17:16,520 --> 00:17:19,840
So to make this tangible, let's stop talking in abstractions.

340
00:17:19,840 --> 00:17:22,560
Let's walk through a set of real world patterns.

341
00:17:22,560 --> 00:17:26,360
Manufacturing, financial services, healthcare, retail and professional services.

342
00:17:26,360 --> 00:17:29,280
Different industries, different regulatory pressures, same underlying story.

343
00:17:29,280 --> 00:17:32,560
The platform was secure, governance disappeared in the control plane.

344
00:17:32,560 --> 00:17:36,800
Scenario one, global manufacturing, ERP data leaks through connectors.

345
00:17:36,800 --> 00:17:41,320
Take a global manufacturing company, centralized ERP running in a secure data center.

346
00:17:41,320 --> 00:17:45,320
Regional finance teams scattered across plans in Europe, Asia, North America, tight change

347
00:17:45,320 --> 00:17:47,040
control on the ERP itself.

348
00:17:47,040 --> 00:17:51,040
Audited, segregation of duties, all the classic controls, then someone discovers power

349
00:17:51,040 --> 00:17:52,040
automate.

350
00:17:52,040 --> 00:17:56,560
Original finance analyst is tired of downloading CSVs from ERP, cleaning them in Excel and

351
00:17:56,560 --> 00:17:58,800
emailing them around for reconciliations.

352
00:17:58,800 --> 00:18:03,600
They open power automate from outlook, see automated business process and start experimenting.

353
00:18:03,600 --> 00:18:06,000
The tenant already has a power platform, DLP policy.

354
00:18:06,000 --> 00:18:07,360
It was created during a pilot.

355
00:18:07,360 --> 00:18:11,560
It marks SAP, SQL, SharePoint and Exchange as business connectors.

356
00:18:11,560 --> 00:18:15,480
It leaves things like Dropbox, Gmail and HTTP in the default bucket.

357
00:18:15,480 --> 00:18:17,000
We revisited it after go-life.

358
00:18:17,000 --> 00:18:21,960
In the default environment, with that default policy, our analyst builds something simple,

359
00:18:21,960 --> 00:18:26,800
a scheduled flow that connects to ERP via a premium connector, pulls yesterday's sales

360
00:18:26,800 --> 00:18:31,960
and inventory, writes the data to a SharePoint list and then emails a summary to a distribution

361
00:18:31,960 --> 00:18:32,960
list.

362
00:18:32,960 --> 00:18:35,520
So far, still inside the boundary, still mostly fine.

363
00:18:35,520 --> 00:18:38,520
Then a plant manager says, "I'd love to see this on my personal device.

364
00:18:38,520 --> 00:18:40,720
I don't want to VPN into anything."

365
00:18:40,720 --> 00:18:42,800
Someone suggests, "Just send it to my Gmail as well.

366
00:18:42,800 --> 00:18:44,640
I'll forward it where it needs to go."

367
00:18:44,640 --> 00:18:48,720
The analyst adds a second action to the flow, send an email via the outlook, come connector

368
00:18:48,720 --> 00:18:53,400
to whatever external addresses are needed, attaching the CSV output.

369
00:18:53,400 --> 00:18:56,280
From their perspective, this is a harmless convenience.

370
00:18:56,280 --> 00:18:58,880
From a DLP perspective, something important just happened.

371
00:18:58,880 --> 00:19:03,040
ERP data that used to live only in a tightly controlled SAP landscape is now flowing through

372
00:19:03,040 --> 00:19:08,760
power automate into SharePoint, into Exchange and out through a consumer email service.

373
00:19:08,760 --> 00:19:12,560
All because the original DLP policy never drew a hard boundary between enterprise systems

374
00:19:12,560 --> 00:19:13,760
and consumer services.

375
00:19:13,760 --> 00:19:15,320
Fast forward six months.

376
00:19:15,320 --> 00:19:19,680
The COE starter kit, if it exists, shows a connector inventory with both business and

377
00:19:19,680 --> 00:19:22,360
non-business connectors active in the default environment.

378
00:19:22,360 --> 00:19:26,800
There's a DLP policy definition called ERP pilot that still has outlook, come classified

379
00:19:26,800 --> 00:19:27,800
as business.

380
00:19:27,800 --> 00:19:28,800
Nobody remembers why.

381
00:19:28,800 --> 00:19:33,000
The admin center has usage reports, but nobody's correlating them with data classification.

382
00:19:33,000 --> 00:19:37,160
An internal audit kicks off, not because of power platform, but because of a broader GDPR

383
00:19:37,160 --> 00:19:38,160
review.

384
00:19:38,160 --> 00:19:39,160
Pause here.

385
00:19:39,160 --> 00:19:40,400
This is the part most audits fail on.

386
00:19:40,400 --> 00:19:41,560
They follow the data.

387
00:19:41,560 --> 00:19:45,960
They find SAP tables with custom information, they find the power automate flow that touches

388
00:19:45,960 --> 00:19:46,960
those tables.

389
00:19:46,960 --> 00:19:49,920
They see it pushing data into SharePoint lists with permissive access.

390
00:19:49,920 --> 00:19:55,800
They find email logs showing CSVs with customer IDs being sent to personal inboxes for convenience.

391
00:19:55,800 --> 00:19:59,360
At that moment, every control you built around your ERP is irrelevant.

392
00:19:59,360 --> 00:20:02,440
The effective boundary is now the weakest connector in the chain.

393
00:20:02,440 --> 00:20:05,520
When the auditors ask, where can this ERP data go?

394
00:20:05,520 --> 00:20:10,040
Your diagrams show firewalls, roll-based access and carefully controlled integrations.

395
00:20:10,040 --> 00:20:12,120
Your automate doesn't appear anywhere on the slide.

396
00:20:12,120 --> 00:20:14,200
But in the tenant, the reality is different.

397
00:20:14,200 --> 00:20:19,840
The DLP policy never said data from ERP and data verse in this environment cannot be combined

398
00:20:19,840 --> 00:20:22,240
with consumer email or consumer storage.

399
00:20:22,240 --> 00:20:26,800
Nobody ran a DLP impact analysis when those connectors were moved into business for a one-off

400
00:20:26,800 --> 00:20:27,800
project.

401
00:20:27,800 --> 00:20:29,520
Nobody reviewed connector usage by data domain.

402
00:20:29,520 --> 00:20:30,760
This is not a hacker problem.

403
00:20:30,760 --> 00:20:32,200
This is a DLP design problem.

404
00:20:32,200 --> 00:20:35,200
If you cannot answer with evidence, where can this data go?

405
00:20:35,200 --> 00:20:38,680
Your power platform DLP policies have already failed.

406
00:20:38,680 --> 00:20:41,400
Regardless of how strong your underlying ERP security is.

407
00:20:41,400 --> 00:20:42,720
Notice what didn't fail here.

408
00:20:42,720 --> 00:20:44,560
EntraID still required authentication.

409
00:20:44,560 --> 00:20:45,600
Encryption still worked.

410
00:20:45,600 --> 00:20:48,200
The connectors did exactly what they were designed to do.

411
00:20:48,200 --> 00:20:50,760
The platform honored the policies it was given.

412
00:20:50,760 --> 00:20:52,360
The failure was architectural.

413
00:20:52,360 --> 00:20:56,480
You treated DLP as a checkbox instead of as an expression of data governance.

414
00:20:56,480 --> 00:21:01,440
You allowed business and non-business connectors to coexist in the same environment where regulated

415
00:21:01,440 --> 00:21:03,600
ERP data was being processed.

416
00:21:03,600 --> 00:21:09,080
You never revisited the policy when power platform moved from pilot to production reality.

417
00:21:09,080 --> 00:21:13,640
Multiply that pattern across payroll exports, HR data, supplier pricing, engineering drawings,

418
00:21:13,640 --> 00:21:18,840
and you get the real shadow IT story, not rogue sass, but sanctioned automations quietly

419
00:21:18,840 --> 00:21:21,480
bypassing your original data flow assumptions.

420
00:21:21,480 --> 00:21:25,200
So the lesson from global manufacturing is simple but non-negotiable.

421
00:21:25,200 --> 00:21:29,200
If your DLP strategy doesn't start from data classification and answer, where can

422
00:21:29,200 --> 00:21:32,040
this data go and where can it never go?

423
00:21:32,040 --> 00:21:35,440
You have already accepted data exfiltration as a probabilistic outcome.

424
00:21:35,440 --> 00:21:36,440
This was not a breach.

425
00:21:36,440 --> 00:21:37,520
This was a boundary failure.

426
00:21:37,520 --> 00:21:39,120
The platform was secure.

427
00:21:39,120 --> 00:21:41,240
Governance disappeared in the control plane.

428
00:21:41,240 --> 00:21:45,680
Scenario 2, financial services, audit fails on ownership and shadow IT.

429
00:21:45,680 --> 00:21:48,280
Now shift to a regulated financial services organization.

430
00:21:48,280 --> 00:21:53,080
They have been empowering the business with power apps and power automate for years.

431
00:21:53,080 --> 00:21:56,560
Internal comms, celebrated citizen development, licensing is generous.

432
00:21:56,560 --> 00:21:59,760
Business units can request environments with a one-page form.

433
00:21:59,760 --> 00:22:03,160
In paper, it looks like a successful digital transformation.

434
00:22:03,160 --> 00:22:04,720
What they never built was an ownership model.

435
00:22:04,720 --> 00:22:07,960
There is a center of excellence but it is mostly a reporting function.

436
00:22:07,960 --> 00:22:12,560
It runs the COE starter kit, sends out a quarterly dashboard and hosts an occasional

437
00:22:12,560 --> 00:22:14,200
maker community call.

438
00:22:14,200 --> 00:22:16,480
It does not actually own a governance operating model.

439
00:22:16,480 --> 00:22:18,200
By year three the numbers look impressive.

440
00:22:18,200 --> 00:22:20,680
The COE dashboards show thousands of apps and flows.

441
00:22:20,680 --> 00:22:21,680
Adoption is up.

442
00:22:21,680 --> 00:22:25,720
Every major business line has critical automations sitting on power platform.

443
00:22:25,720 --> 00:22:29,920
Some are IT-built, many are not, nobody can tell at a glance which is which.

444
00:22:29,920 --> 00:22:31,320
Then a regulatory audit arrives.

445
00:22:31,320 --> 00:22:33,080
The scope isn't power platform.

446
00:22:33,080 --> 00:22:37,840
The scope is payment processing, customer onboarding, sanction screening, classic financial

447
00:22:37,840 --> 00:22:39,240
services topics.

448
00:22:39,240 --> 00:22:43,040
But because those processes now depend on low-code automation, power apps and power

449
00:22:43,040 --> 00:22:45,520
automate show up in the process maps.

450
00:22:45,520 --> 00:22:47,720
The auditors ask a simple question.

451
00:22:47,720 --> 00:22:51,960
Which of these automations are in scope and who is accountable for each of them?

452
00:22:51,960 --> 00:22:53,120
The enterprise scrambles.

453
00:22:53,120 --> 00:22:55,040
They open the COE inventory.

454
00:22:55,040 --> 00:22:59,120
They see for example 4000 plus cloud flows across all environments.

455
00:22:59,120 --> 00:23:02,120
Hundreds marked as runs frequently in production environments.

456
00:23:02,120 --> 00:23:07,520
A surprising number where the owner is a user account flagged as a lever in enter ID.

457
00:23:07,520 --> 00:23:11,920
Many apps with descriptions like onboarding V2 or payments helper with no business service

458
00:23:11,920 --> 00:23:12,920
mapping.

459
00:23:12,920 --> 00:23:14,240
They export the list to Excel.

460
00:23:14,240 --> 00:23:16,600
They start filtering by environment name.

461
00:23:16,600 --> 00:23:20,200
Proud payments by team, customer onboarding, risk KYC.

462
00:23:20,200 --> 00:23:21,960
That helps a little but not enough.

463
00:23:21,960 --> 00:23:23,760
Environment naming was never enforced.

464
00:23:23,760 --> 00:23:27,560
Some critical flows still live in a generic shared-proud environment created by a project

465
00:23:27,560 --> 00:23:28,560
years ago.

466
00:23:28,560 --> 00:23:30,640
Per view logs confirm usage.

467
00:23:30,640 --> 00:23:32,640
Flow's tied to lever accounts are still running.

468
00:23:32,640 --> 00:23:36,120
Apps that look like prototypes are being opened hundreds of times a day.

469
00:23:36,120 --> 00:23:40,120
There is clear business dependency but no clear owner in any system of record.

470
00:23:40,120 --> 00:23:42,440
The auditors come back to their original question.

471
00:23:42,440 --> 00:23:46,760
For each automation that touches in scope processes who is the accountable business owner

472
00:23:46,760 --> 00:23:48,400
and what is the life cycle control?

473
00:23:48,400 --> 00:23:49,400
You don't have an answer.

474
00:23:49,400 --> 00:23:53,040
You have an Excel export, a QE dashboard and a lot of tribal knowledge.

475
00:23:53,040 --> 00:23:55,840
For governance perspective three things went wrong here.

476
00:23:55,840 --> 00:23:58,840
First there was no power platform solution ownership model.

477
00:23:58,840 --> 00:23:59,840
Nobody made no owner.

478
00:23:59,840 --> 00:24:01,160
It's a no app a rule.

479
00:24:01,160 --> 00:24:05,080
Nobody required that every production solution have a named business owner.

480
00:24:05,080 --> 00:24:08,880
A technical owner, a mapped business service or process.

481
00:24:08,880 --> 00:24:10,600
A documented life cycle.

482
00:24:10,600 --> 00:24:13,160
When it was last reviewed what happens if the owner leaves.

483
00:24:13,160 --> 00:24:15,840
Second, there was no life cycle management.

484
00:24:15,840 --> 00:24:20,360
Flow's were created as pilots then quietly became production because they worked.

485
00:24:20,360 --> 00:24:21,840
There's left the company.

486
00:24:21,840 --> 00:24:25,840
Their entra idea accounts were disabled but their apps and flows were reassigned to generic

487
00:24:25,840 --> 00:24:28,760
admin accounts without any business review.

488
00:24:28,760 --> 00:24:32,520
Dependency grew but nothing in the control plane reflected that criticality.

489
00:24:32,520 --> 00:24:34,600
Third, the COE was reporting not governing.

490
00:24:34,600 --> 00:24:38,080
It surfaced the existence of assets but didn't drive decisions.

491
00:24:38,080 --> 00:24:42,680
No one had a standing process like every quarter we would identify often apps and flows

492
00:24:42,680 --> 00:24:46,560
in production environments and either assign owners or decommission them.

493
00:24:46,560 --> 00:24:48,800
The COE had telemetry, not authority.

494
00:24:48,800 --> 00:24:53,040
So during the audit phrases like shadow it start appearing in the notes.

495
00:24:53,040 --> 00:24:54,920
But this isn't classic shadow IT.

496
00:24:54,920 --> 00:24:57,000
Rogue SaaS purchased on a credit card.

497
00:24:57,000 --> 00:25:01,080
These are sanctioned tools on a sanctioned platform running inside your tenant, built

498
00:25:01,080 --> 00:25:05,040
with your licenses over your data, under your entra idea.

499
00:25:05,040 --> 00:25:07,000
The only thing missing is ownership.

500
00:25:07,000 --> 00:25:12,080
From the auditors standpoint an often solution that moves money on board's customers or touches

501
00:25:12,080 --> 00:25:13,920
KYC is not a hygiene issue.

502
00:25:13,920 --> 00:25:14,920
It's a control failure.

503
00:25:14,920 --> 00:25:17,520
There is no accountable person to question.

504
00:25:17,520 --> 00:25:21,440
No documented change history that anyone trusts and no guarantee that the logic has ever

505
00:25:21,440 --> 00:25:23,040
been tested against current policy.

506
00:25:23,040 --> 00:25:24,680
This was not a shadow IT problem.

507
00:25:24,680 --> 00:25:26,360
This was a missing ownership problem.

508
00:25:26,360 --> 00:25:28,480
And it's important to see how subtle the path was.

509
00:25:28,480 --> 00:25:33,240
At no point did someone say we choose to run regulated processes on unowned flows.

510
00:25:33,240 --> 00:25:35,760
What happened was the business needed automation.

511
00:25:35,760 --> 00:25:37,320
Power platform made it easy to build.

512
00:25:37,320 --> 00:25:39,480
The COE celebrated adoption.

513
00:25:39,480 --> 00:25:42,840
Nobody hardwired ownership and life cycle into the operating model.

514
00:25:42,840 --> 00:25:45,040
By the time audit arrives it's too late to retrofit.

515
00:25:45,040 --> 00:25:49,280
You can clean up going forward but you can't convincingly reconstruct years of ownership

516
00:25:49,280 --> 00:25:51,360
history for thousands of artifacts.

517
00:25:51,360 --> 00:25:53,560
So the lesson from financial services is this.

518
00:25:53,560 --> 00:25:58,120
If you cannot produce, on demand, a list of production apps and flows with named business

519
00:25:58,120 --> 00:26:00,960
owners and life cycle states, you don't have a governance model.

520
00:26:00,960 --> 00:26:02,200
You have a user report.

521
00:26:02,200 --> 00:26:03,200
This was not shadow it.

522
00:26:03,200 --> 00:26:04,600
Now this was missing ownership.

523
00:26:04,600 --> 00:26:06,120
The platform was secure.

524
00:26:06,120 --> 00:26:09,280
Governance disappeared in the control plane or to put it more bluntly.

525
00:26:09,280 --> 00:26:13,400
If you already have a COE but it doesn't enforce ownership and life cycle you don't have governance.

526
00:26:13,400 --> 00:26:14,960
You have a meeting.

527
00:26:14,960 --> 00:26:18,200
In scenario three, healthcare, PHI in the wrong environment.

528
00:26:18,200 --> 00:26:21,680
Now take a healthcare provider operating under hyper equivalent regulation.

529
00:26:21,680 --> 00:26:24,240
They adopted power platform aggressively during a crisis.

530
00:26:24,240 --> 00:26:25,680
Clinics needed triage apps.

531
00:26:25,680 --> 00:26:27,040
Labs needed intake forms.

532
00:26:27,040 --> 00:26:29,560
Care teams needed lightweight tracking for follow ups.

533
00:26:29,560 --> 00:26:34,240
Traditional build cycles were too slow so power apps and power automate filled the gap.

534
00:26:34,240 --> 00:26:35,840
It did one thing right at the start.

535
00:26:35,840 --> 00:26:37,760
They created multiple environments.

536
00:26:37,760 --> 00:26:41,840
There was clinic apps, back office, research and a generic broadshed.

537
00:26:41,840 --> 00:26:45,600
They even created a PHI restricted environment because someone at least recognized that

538
00:26:45,600 --> 00:26:48,880
protected health information should live somewhere special.

539
00:26:48,880 --> 00:26:51,400
On paper that looks like an environment strategy.

540
00:26:51,400 --> 00:26:53,600
In reality it was just a list of names.

541
00:26:53,600 --> 00:26:55,640
The lesson here should land early.

542
00:26:55,640 --> 00:26:57,840
Environment names are not classification.

543
00:26:57,840 --> 00:27:02,920
If you don't bind environments to concrete data rules you've just created labels, not controls.

544
00:27:02,920 --> 00:27:05,560
Nobody ever mapped those environments to data classification.

545
00:27:05,560 --> 00:27:09,000
Nobody wrote down PHI is only allowed in these environments.

546
00:27:09,000 --> 00:27:12,680
One PHI must never be in them, specific connectors are banned here.

547
00:27:12,680 --> 00:27:15,960
Every app here is automatically in regulatory scope.

548
00:27:15,960 --> 00:27:17,960
The names were suggestive, not authoritative.

549
00:27:17,960 --> 00:27:19,640
A clinic team needs a triage app.

550
00:27:19,640 --> 00:27:22,640
They work with a contractor who has built similar things before.

551
00:27:22,640 --> 00:27:26,000
The contractor is an experienced power app smaker, comfortable with dataverse.

552
00:27:26,000 --> 00:27:28,040
They ask for an environment to build in.

553
00:27:28,040 --> 00:27:31,000
Someone in IT says use clinic apps, that's what the name suggests.

554
00:27:31,000 --> 00:27:33,560
In that environment, dataverse is provisioned.

555
00:27:33,560 --> 00:27:37,280
The contractor creates tables for patients, encounters, symptoms and notes.

556
00:27:37,280 --> 00:27:41,520
They configure a model driven app for staff and a canvas app for quick intake on tablets.

557
00:27:41,520 --> 00:27:44,800
It works, the clinics love it, so far still relatively contained.

558
00:27:44,800 --> 00:27:46,560
Then a new use case emerges.

559
00:27:46,560 --> 00:27:51,200
Tracking patients refer to specialists including diagnoses, medications and lab results.

560
00:27:51,200 --> 00:27:54,800
That dataset is clearly PHI, not just operational metadata.

561
00:27:54,800 --> 00:27:58,560
A security conscious architect suggests we should put that in PHI restricted.

562
00:27:58,560 --> 00:27:59,960
That's why we created it.

563
00:27:59,960 --> 00:28:03,920
Under time pressure the contractor copies the existing dataverse tables and app configuration

564
00:28:03,920 --> 00:28:06,720
from clinic apps into PHI restricted.

565
00:28:06,720 --> 00:28:12,200
They export a solution imported into the PHI environment and then fix up the roles to match.

566
00:28:12,200 --> 00:28:14,560
Here is where the architectural failure happens.

567
00:28:14,560 --> 00:28:19,680
Instead of designing roles from first principles for PHI restricted, they copy the security

568
00:28:19,680 --> 00:28:21,520
roles from clinic apps.

569
00:28:21,520 --> 00:28:25,840
Those roles were designed for a broad set of clinic staff, reception, nurses, doctors and

570
00:28:25,840 --> 00:28:27,360
some back office coordinators.

571
00:28:27,360 --> 00:28:32,160
They granted table level read access to patient and encounter records because in the non-PHI

572
00:28:32,160 --> 00:28:34,320
triage context that was acceptable.

573
00:28:34,320 --> 00:28:38,800
In PHI restricted, that same set of roles now effectively grants large groups of staff access

574
00:28:38,800 --> 00:28:42,880
to diagnosis codes, medication histories and lab values they should never see.

575
00:28:42,880 --> 00:28:46,480
From their perspective nothing seems wrong, users log in with the same accounts.

576
00:28:46,480 --> 00:28:48,640
The app looks similar, they can do their job.

577
00:28:48,640 --> 00:28:49,640
Performance is fine.

578
00:28:49,640 --> 00:28:51,720
Auditing if enabled shows expected activity.

579
00:28:51,720 --> 00:28:55,560
The only hint of a problem appears months later when an internal privacy team performs

580
00:28:55,560 --> 00:28:56,560
a routine check.

581
00:28:56,560 --> 00:28:59,440
They pull an environment inventory, they see PHI restricted.

582
00:28:59,440 --> 00:29:02,960
Good, they see tables with names that clearly contain PHI.

583
00:29:02,960 --> 00:29:06,240
But then they look at the dataverse security roles and their assignments.

584
00:29:06,240 --> 00:29:09,920
They find a generic clinic user role with read access to PHI tables.

585
00:29:09,920 --> 00:29:13,600
That role assigned to large security groups covering wide swaths of staff.

586
00:29:13,600 --> 00:29:17,920
No differentiation between care teams or specialties or minimum necessary access.

587
00:29:17,920 --> 00:29:20,400
No documentation linking roles to drop functions.

588
00:29:20,400 --> 00:29:25,200
They compare that to the role model in the underlying EHR system, which is tightly segmented

589
00:29:25,200 --> 00:29:26,680
by specialty and location.

590
00:29:26,680 --> 00:29:28,480
The gap is obvious.

591
00:29:28,480 --> 00:29:32,000
If you remember one thing from this healthcare example, remember this.

592
00:29:32,000 --> 00:29:36,400
Having a role model from a non-PHI environment into a PHI environment is not reuse.

593
00:29:36,400 --> 00:29:39,560
It's a compliance violation waiting to be discovered.

594
00:29:39,560 --> 00:29:44,680
Functionally PHI in the power platform environment is far more broadly visible than PHI in the primary

595
00:29:44,680 --> 00:29:45,680
clinical system.

596
00:29:45,680 --> 00:29:49,720
Not because anyone overrode encryption or broke authentication, but because they copied

597
00:29:49,720 --> 00:29:55,840
a convenience oriented role model from a non-PHI context into a PHI context without redesign,

598
00:29:55,840 --> 00:29:56,840
auditors dig deeper.

599
00:29:56,840 --> 00:29:59,040
They ask for a field level security matrix.

600
00:29:59,040 --> 00:30:00,040
It doesn't exist.

601
00:30:00,040 --> 00:30:01,720
Field level security was never turned on.

602
00:30:01,720 --> 00:30:06,360
Social security numbers addresses diagnosis descriptions all treated as regular columns.

603
00:30:06,360 --> 00:30:10,400
They ask for a record of who approved this access design for PHI restricted.

604
00:30:10,400 --> 00:30:11,400
There is no record.

605
00:30:11,400 --> 00:30:15,000
There was a project plan, some emails and a deployment ticket that said promote to PHI

606
00:30:15,000 --> 00:30:16,000
restricted.

607
00:30:16,000 --> 00:30:20,360
Nobody with formal privacy accountability signed off on the dataverse security configuration.

608
00:30:20,360 --> 00:30:22,800
From a regulatory standpoint, this is not an edge case.

609
00:30:22,800 --> 00:30:24,680
It's a systematic failure.

610
00:30:24,680 --> 00:30:27,280
Environment strategy without data classification is not neutral.

611
00:30:27,280 --> 00:30:28,280
It's a compliance trap.

612
00:30:28,280 --> 00:30:32,600
You created a PHI environment but you never bound it to a stricter security model.

613
00:30:32,600 --> 00:30:35,680
You allowed roles to be copy-pasted from non-PHI spaces.

614
00:30:35,680 --> 00:30:38,720
You never mandated field level security for sensitive attributes.

615
00:30:38,720 --> 00:30:42,640
You never defined which person has existed in that environment and how least privilege

616
00:30:42,640 --> 00:30:43,840
would be enforced.

617
00:30:43,840 --> 00:30:45,960
So you end up in the worst possible position.

618
00:30:45,960 --> 00:30:50,320
You can't honestly claim ignorance because the environment is literally called PHI restricted,

619
00:30:50,320 --> 00:30:54,240
but you also can't demonstrate that you applied a proportional security design.

620
00:30:54,240 --> 00:30:55,680
This was not an encryption problem.

621
00:30:55,680 --> 00:30:56,920
This was a role design problem.

622
00:30:56,920 --> 00:30:58,080
The platform was secure.

623
00:30:58,080 --> 00:31:02,760
Governance disappeared in the control plane and again, the path was entirely understandable.

624
00:31:02,760 --> 00:31:06,880
Time pressure, reuse of existing patterns, lack of a platform team with authority over

625
00:31:06,880 --> 00:31:11,840
environment design and a deeply human instinct to copy something that already works instead

626
00:31:11,840 --> 00:31:14,040
of designing from scratch.

627
00:31:14,040 --> 00:31:16,200
The lesson from healthcare is straightforward.

628
00:31:16,200 --> 00:31:20,360
If your environment strategy is based on team names instead of data classification,

629
00:31:20,360 --> 00:31:21,800
you haven't reduced risk.

630
00:31:21,800 --> 00:31:24,360
You've just hidden it behind friendly labels.

631
00:31:24,360 --> 00:31:28,920
Mario 4, retail, business critical app dies with its creator.

632
00:31:28,920 --> 00:31:30,160
Now move into retail.

633
00:31:30,160 --> 00:31:34,800
A large retailer with thousands of stores has been modernizing store operations.

634
00:31:34,800 --> 00:31:38,640
Task management, shrink reporting, inventory exceptions, maintenance tickets are all the

635
00:31:38,640 --> 00:31:43,320
small workflows that used to live in binders and email threads are slowly moving onto power

636
00:31:43,320 --> 00:31:45,400
apps and power automate.

637
00:31:45,400 --> 00:31:48,240
One store manager is particularly good with technology.

638
00:31:48,240 --> 00:31:50,720
They start as a classic citizen developer.

639
00:31:50,720 --> 00:31:55,280
Just a simple checklist app, then a basic incident logging tool, then a more sophisticated solution

640
00:31:55,280 --> 00:31:59,680
that wires together inventory data, staffing and maintenance.

641
00:31:59,680 --> 00:32:03,000
Over a couple of years, that side project quietly becomes business critical.

642
00:32:03,000 --> 00:32:05,280
Here's how it happens.

643
00:32:05,280 --> 00:32:08,040
The original app tracks store incidents.

644
00:32:08,040 --> 00:32:13,040
Spills, breakages, equipment issues, over time it grows features, integration with a shared

645
00:32:13,040 --> 00:32:17,360
excel file for tracking costs, a power automate flow that notifies maintenance when freezer

646
00:32:17,360 --> 00:32:19,600
temperatures cross a threshold.

647
00:32:19,600 --> 00:32:23,520
Another flow that sends summaries to regional managers every Monday, a canvas app embedded

648
00:32:23,520 --> 00:32:25,680
in teams that staff use on handhelds.

649
00:32:25,680 --> 00:32:30,120
The app lives in what was originally a department environment called Ops Tools.

650
00:32:30,120 --> 00:32:32,400
Nobody ever reclassified it as production.

651
00:32:32,400 --> 00:32:37,560
Nobody updated the environment strategy when this solution became central to store operations.

652
00:32:37,560 --> 00:32:38,560
Ownership is informal.

653
00:32:38,560 --> 00:32:40,160
The creator is the store manager.

654
00:32:40,160 --> 00:32:43,760
They are the environment admin, the app owner, the person everyone pings when something

655
00:32:43,760 --> 00:32:44,760
looks odd.

656
00:32:44,760 --> 00:32:48,360
It is dimly aware of the solution but happy to see the stores innovating.

657
00:32:48,360 --> 00:32:52,240
There is no race, there is no ticket queue, there is no documented support model, then the

658
00:32:52,240 --> 00:32:53,240
creator leaves.

659
00:32:53,240 --> 00:32:57,480
Maybe they get promoted to a different business unit, maybe they move to a competitor, maybe

660
00:32:57,480 --> 00:33:02,200
they take a sabbatical, their intraid account is disabled as part of the standard HR off-boarding

661
00:33:02,200 --> 00:33:03,200
process.

662
00:33:03,200 --> 00:33:04,880
In intraid, that's the end of the story.

663
00:33:04,880 --> 00:33:07,680
In power platform, it's the start of a slow motion incident.

664
00:33:07,680 --> 00:33:09,920
Initially, nothing obvious breaks.

665
00:33:09,920 --> 00:33:13,280
The app still opens because users have direct share permissions.

666
00:33:13,280 --> 00:33:17,640
Some flows keep running because ownership was quietly reassigned to a generic admin account

667
00:33:17,640 --> 00:33:19,560
when the user was deprovisioned.

668
00:33:19,560 --> 00:33:21,680
From the store's perspective, life goes on.

669
00:33:21,680 --> 00:33:23,320
But entropy is already in motion.

670
00:33:23,320 --> 00:33:25,880
A schema change happens in the underlying data source.

671
00:33:25,880 --> 00:33:29,720
A column is added to the Excel sheet or a new field appears in dataverse because someone

672
00:33:29,720 --> 00:33:32,000
extended the model for a related project.

673
00:33:32,000 --> 00:33:34,000
The app wasn't built with that change in mind.

674
00:33:34,000 --> 00:33:35,600
A formula breaks in one screen.

675
00:33:35,600 --> 00:33:38,360
Staff start seeing errors when they submit certain types of incidents.

676
00:33:38,360 --> 00:33:40,320
They open tickets with the central service desk.

677
00:33:40,320 --> 00:33:42,520
The service desk looks in their ITSM system.

678
00:33:42,520 --> 00:33:44,400
There is no CI record for this app.

679
00:33:44,400 --> 00:33:45,720
No support team.

680
00:33:45,720 --> 00:33:47,160
No documented owner.

681
00:33:47,160 --> 00:33:52,080
The ticket bounces between applications via store operations and infrastructure.

682
00:33:52,080 --> 00:33:53,400
Nobody can answer a simple question.

683
00:33:53,400 --> 00:33:56,000
Who is responsible for fixing this power app?

684
00:33:56,000 --> 00:33:59,880
In parallel, one of the flows that sends weekly summaries starts failing.

685
00:33:59,880 --> 00:34:03,600
The failure shows up in power, automated as a run history full of red exclamation marks.

686
00:34:03,600 --> 00:34:05,200
The notification email stop.

687
00:34:05,200 --> 00:34:08,480
Regional managers assume the stores are just having a quiet week.

688
00:34:08,480 --> 00:34:13,040
After a month, someone notices that incident volumes look suspiciously low, they escalate.

689
00:34:13,040 --> 00:34:15,440
It finally goes into the power platform admin center.

690
00:34:15,440 --> 00:34:16,440
They find the app.

691
00:34:16,440 --> 00:34:17,440
They can see usage patterns.

692
00:34:17,440 --> 00:34:19,120
There are heavy in certain regions.

693
00:34:19,120 --> 00:34:20,960
Daily usage across hundreds of users.

694
00:34:20,960 --> 00:34:25,320
They see that the current owner is a generic admin account with no human tied to it.

695
00:34:25,320 --> 00:34:29,600
They see related flows, some suspended due to errors, some still running.

696
00:34:29,600 --> 00:34:32,960
They ask the COE team who built this and where is the documentation there.

697
00:34:32,960 --> 00:34:37,040
The COE team can tell them that the original creator's UPN was bound to the app.

698
00:34:37,040 --> 00:34:40,200
They can show when an ownership was transferred to the admin account.

699
00:34:40,200 --> 00:34:42,080
They can export the dependency graph.

700
00:34:42,080 --> 00:34:45,600
What they can't do is tell them why the app was designed the way it was, what business

701
00:34:45,600 --> 00:34:48,400
rules it encodes or what the acceptable behavior is.

702
00:34:48,400 --> 00:34:51,240
From the business perspective, this is a production outage.

703
00:34:51,240 --> 00:34:53,280
Store staff revert to manual reporting.

704
00:34:53,280 --> 00:34:54,880
Spread sheets reappear.

705
00:34:54,880 --> 00:34:56,280
Incidents go unlogged.

706
00:34:56,280 --> 00:34:57,280
Maintenance is slower.

707
00:34:57,280 --> 00:35:01,160
There is no official severity one incident in your classic IT systems, but the impact is

708
00:35:01,160 --> 00:35:02,160
real.

709
00:35:02,160 --> 00:35:06,440
From a governance perspective, this is the inevitable outcome of one design choice.

710
00:35:06,440 --> 00:35:10,320
You allow the business critical app to exist in production without a clear ownership and

711
00:35:10,320 --> 00:35:11,640
life cycle model.

712
00:35:11,640 --> 00:35:15,360
There was no rule that said no owner is no app.

713
00:35:15,360 --> 00:35:18,960
There was no requirement that any app with certain usage or impact be onboarded into your

714
00:35:18,960 --> 00:35:20,400
standard support model.

715
00:35:20,400 --> 00:35:25,320
There was no life cycle policy that said if the owner is a lever, the app must be reviewed

716
00:35:25,320 --> 00:35:26,400
or decommissioned.

717
00:35:26,400 --> 00:35:28,360
This was not a platform reliability problem.

718
00:35:28,360 --> 00:35:30,440
This was a life cycle governance problem.

719
00:35:30,440 --> 00:35:34,280
The uncomfortable part is that the platform behaved exactly as designed.

720
00:35:34,280 --> 00:35:36,200
Store apps didn't randomly delete anything.

721
00:35:36,200 --> 00:35:38,960
Power automate didn't spontaneously corrupt your logic.

722
00:35:38,960 --> 00:35:43,120
The admin center even had enough telemetry to warn you if someone had been looking.

723
00:35:43,120 --> 00:35:47,880
Heavy usage tied to a small number of owners, flows failing repeatedly orfant assets.

724
00:35:47,880 --> 00:35:49,160
Governance chose not to act.

725
00:35:49,160 --> 00:35:51,600
So the lesson from retail is blunt.

726
00:35:51,600 --> 00:35:55,000
If an app is important enough that you'd open a severity one incident when it breaks,

727
00:35:55,000 --> 00:35:59,440
it is important enough to have a documented owner, a support model and a life cycle.

728
00:35:59,440 --> 00:36:02,960
Pause on this because it's the only rule that consistently survives incidents.

729
00:36:02,960 --> 00:36:04,680
No owner, X no app.

730
00:36:04,680 --> 00:36:06,600
No owner, X no app is not optional.

731
00:36:06,600 --> 00:36:10,960
It is your only realistic business continuity policy for citizen build solutions.

732
00:36:10,960 --> 00:36:13,040
This was not a platform reliability problem.

733
00:36:13,040 --> 00:36:14,560
The platform was secure.

734
00:36:14,560 --> 00:36:16,560
Governance disappeared in the control plane.

735
00:36:16,560 --> 00:36:18,680
Scenario 5, professional services.

736
00:36:18,680 --> 00:36:20,880
Copilot quietly multiplies risk.

737
00:36:20,880 --> 00:36:22,920
Now let's look at a professional services firm.

738
00:36:22,920 --> 00:36:24,240
Legal consulting tax?

739
00:36:24,240 --> 00:36:25,320
Pick your poison.

740
00:36:25,320 --> 00:36:26,640
The common pattern is the same.

741
00:36:26,640 --> 00:36:31,040
Expensive humans, time and materials billing, and a lot of very sensitive documents.

742
00:36:31,040 --> 00:36:33,760
Co-pilot's ownership is under pressure to do something with AI.

743
00:36:33,760 --> 00:36:35,960
They see Microsoft copilot everywhere.

744
00:36:35,960 --> 00:36:39,680
Slide decks promise productivity gains, so they make the predictable move.

745
00:36:39,680 --> 00:36:44,640
Turn on copilot capabilities in power platform to increase efficiency for knowledge workers.

746
00:36:44,640 --> 00:36:45,720
There is just one problem.

747
00:36:45,720 --> 00:36:48,920
They do this before they can even govern human build apps properly.

748
00:36:48,920 --> 00:36:52,720
In the tenant, there is already a mix of power apps and power automate flows.

749
00:36:52,720 --> 00:36:54,200
Matter intake forms.

750
00:36:54,200 --> 00:36:56,720
Conflict check automations, document review trackers.

751
00:36:56,720 --> 00:36:58,640
Simple time entry helpers tied into billing.

752
00:36:58,640 --> 00:36:59,880
Ownership is patchy.

753
00:36:59,880 --> 00:37:04,560
Some live in IT owned environments, others in team spaces, many in a generic apps prod environment

754
00:37:04,560 --> 00:37:05,960
created during an early pilot.

755
00:37:05,960 --> 00:37:08,760
The COE has inventory but not much classification.

756
00:37:08,760 --> 00:37:11,800
DLP policies exist but they were written with classic connectors in mind.

757
00:37:11,800 --> 00:37:16,120
SharePoint, Exchange, SQL, a handful of line of business APIs.

758
00:37:16,120 --> 00:37:20,800
When copilot studio and copilot features in power apps and power automate light up, the

759
00:37:20,800 --> 00:37:22,720
makers don't get a new governance story.

760
00:37:22,720 --> 00:37:24,240
They just get a new button.

761
00:37:24,240 --> 00:37:25,600
Describe what you want to build.

762
00:37:25,600 --> 00:37:30,680
A senior associate types create an app that tracks matters with fields for client jurisdiction,

763
00:37:30,680 --> 00:37:34,040
practice area, lead partner and current status.

764
00:37:34,040 --> 00:37:36,920
Add a screen that lists open matters by deadline.

765
00:37:36,920 --> 00:37:39,920
Copilot scaffolds a dataverse table, some screens a couple of views.

766
00:37:39,920 --> 00:37:42,680
It's not perfect but it's good enough to iterate on.

767
00:37:42,680 --> 00:37:46,040
They tweak it, wire in some flows for notifications and publish.

768
00:37:46,040 --> 00:37:49,880
In a day they've shipped what would have taken weeks to get through traditional IT.

769
00:37:49,880 --> 00:37:52,080
Repeat that pattern across dozens of teams.

770
00:37:52,080 --> 00:37:57,320
HR builds a feedback tracker, tax builds a workflow for extension requests, risk builds a conflicts

771
00:37:57,320 --> 00:37:58,320
review helper.

772
00:37:58,320 --> 00:38:02,560
All of them use copilot to accelerate schema design, formulas and expressions.

773
00:38:02,560 --> 00:38:04,880
Architecturally something quiet and important changes.

774
00:38:04,880 --> 00:38:09,000
You no longer have a need division between IT build apps and business build apps.

775
00:38:09,000 --> 00:38:13,840
You have a fast growing set of AI assisted assets whose intent is only partially visible

776
00:38:13,840 --> 00:38:15,240
in human minds.

777
00:38:15,240 --> 00:38:18,000
The people who built them didn't write every line.

778
00:38:18,000 --> 00:38:20,040
They accepted and tweaked suggestions.

779
00:38:20,040 --> 00:38:21,920
Now look at this from the governance side.

780
00:38:21,920 --> 00:38:23,480
The admin center inventory grows.

781
00:38:23,480 --> 00:38:25,640
You see new apps, new flows, new connections.

782
00:38:25,640 --> 00:38:27,680
Many of them were created via copilot.

783
00:38:27,680 --> 00:38:31,960
But there is no mandatory tagging that says AI generated versus human authored.

784
00:38:31,960 --> 00:38:35,960
There is no required owner metadata beyond the basic maker identity.

785
00:38:35,960 --> 00:38:40,160
There is no prompt logging that says these were the natural language instructions that shaped

786
00:38:40,160 --> 00:38:41,240
this asset.

787
00:38:41,240 --> 00:38:43,240
The CUE dashboards show adoption going up.

788
00:38:43,240 --> 00:38:44,440
There is internal excitement.

789
00:38:44,440 --> 00:38:48,840
Leaders see demos of copilot surfacing key clauses from contracts stored in SharePoint

790
00:38:48,840 --> 00:38:51,120
or summarizing status from dataverse tables.

791
00:38:51,120 --> 00:38:52,400
It looks like innovation.

792
00:38:52,400 --> 00:38:54,280
Then risk and compliance start asking questions.

793
00:38:54,280 --> 00:38:57,280
They pull a list of apps and flows that touch client data.

794
00:38:57,280 --> 00:39:01,360
They want to know which of these were built with copilot, what prompts were used.

795
00:39:01,360 --> 00:39:05,480
Did anyone ask copilot to summarize or transform client documents that contain privileged or

796
00:39:05,480 --> 00:39:06,760
regulated information?

797
00:39:06,760 --> 00:39:09,280
Where are those prompts and intermediate output stored?

798
00:39:09,280 --> 00:39:10,760
You don't have answers.

799
00:39:10,760 --> 00:39:14,920
Copilot usage logs exist at a platform level, but you never wired them into your governance

800
00:39:14,920 --> 00:39:15,920
story.

801
00:39:15,920 --> 00:39:19,480
There is no standard that says every AI assisted asset must be registered with the platform

802
00:39:19,480 --> 00:39:23,320
team, tagged with its risk level and linked to a business owner.

803
00:39:23,320 --> 00:39:27,920
There is no AI specific DLP model that says copilot cannot read from these repositories

804
00:39:27,920 --> 00:39:29,120
or write to those.

805
00:39:29,120 --> 00:39:31,480
So you end up with the worst of both worlds.

806
00:39:31,480 --> 00:39:35,600
On the one hand, you have all the classic low-code risks, unclear ownership, weak environment

807
00:39:35,600 --> 00:39:38,000
strategy, inconsistent DLP.

808
00:39:38,000 --> 00:39:41,800
On the other hand, you've just attached an acceleration engine to that weak governance

809
00:39:41,800 --> 00:39:42,800
model.

810
00:39:42,800 --> 00:39:43,800
Copilot is not misbehaving.

811
00:39:43,800 --> 00:39:46,760
It's doing exactly what it was asked to do.

812
00:39:46,760 --> 00:39:50,440
It's a flow that copies documents from this library to that one.

813
00:39:50,440 --> 00:39:53,640
Suggest columns based on this description of a client matter system.

814
00:39:53,640 --> 00:39:57,280
Write an expression to filter records where status is active and deadline is in the next

815
00:39:57,280 --> 00:39:58,680
14 days.

816
00:39:58,680 --> 00:40:03,080
The trouble is that nobody is systematically reviewing what it produced, where it connected,

817
00:40:03,080 --> 00:40:05,280
or how it changed the shape of data movement.

818
00:40:05,280 --> 00:40:09,320
An internal investigation eventually finds a copilot generated flow that listens to a

819
00:40:09,320 --> 00:40:13,480
SharePoint library where draft contracts are stored sends some of those contracts to

820
00:40:13,480 --> 00:40:15,880
a shared mailbox for a review group.

821
00:40:15,880 --> 00:40:19,280
Logs those summaries in a dataverse table called contract summaries.

822
00:40:19,280 --> 00:40:20,600
The review mailbox is fine.

823
00:40:20,600 --> 00:40:24,560
The dataverse table lives in an environment with Slack DLP rules and broad membership.

824
00:40:24,560 --> 00:40:29,160
Junior staff who should never see the substance of certain deals can now browse summaries.

825
00:40:29,160 --> 00:40:31,920
Again, nothing here breached the core security model.

826
00:40:31,920 --> 00:40:33,920
Entra ID authenticated everyone.

827
00:40:33,920 --> 00:40:35,680
SharePoint permissions were respected.

828
00:40:35,680 --> 00:40:37,920
Dataverse dutifully stored what it was told.

829
00:40:37,920 --> 00:40:42,760
DLP never complained because from its perspective, everything stayed inside business connectors.

830
00:40:42,760 --> 00:40:44,560
This was not an AI safety failure.

831
00:40:44,560 --> 00:40:47,520
This was a governance failure that copilot multiplied.

832
00:40:47,520 --> 00:40:49,160
And that's the pattern to pay attention to.

833
00:40:49,160 --> 00:40:52,960
If you cannot govern human build apps and flows today, if you don't have environment,

834
00:40:52,960 --> 00:40:57,760
strategy, DLP guardrails, ownership, life cycle and metrics, you are not ready to govern

835
00:40:57,760 --> 00:40:59,520
AI generated ones.

836
00:40:59,520 --> 00:41:02,520
Copilot and agente AI are accelerants.

837
00:41:02,520 --> 00:41:07,040
For whatever governance posture you already have, good or bad, most copilot failures will

838
00:41:07,040 --> 00:41:08,640
not look like AI failures.

839
00:41:08,640 --> 00:41:11,840
They will look like ordinary governance failures, just faster.

840
00:41:11,840 --> 00:41:14,880
So the lesson from professional services is simple and uncomfortable.

841
00:41:14,880 --> 00:41:19,600
If your low-code governance framework cannot handle humans, it will not handle agents.

842
00:41:19,600 --> 00:41:22,680
Governance is not a PDF, defining a real operating model.

843
00:41:22,680 --> 00:41:25,120
By this point, the pattern should be obvious.

844
00:41:25,120 --> 00:41:29,720
Manufacturing leaked data because DLP was a one-time configuration, not a living system.

845
00:41:29,720 --> 00:41:33,200
Financial services failed audit because ownership was a slide, not a practice.

846
00:41:33,200 --> 00:41:37,480
Healthcare exposed PHI because environment names pretended to be classification.

847
00:41:37,480 --> 00:41:40,960
Retail broke because life cycle was implicit, not enforced.

848
00:41:40,960 --> 00:41:44,920
Social services multiplied risk because copilot landed on top of all of that.

849
00:41:44,920 --> 00:41:47,560
All of those are symptoms of the same root cause.

850
00:41:47,560 --> 00:41:52,280
You don't have a governance operating model, you have governance documents.

851
00:41:52,280 --> 00:41:55,960
Architecturally, governance has to behave like an operating system, not a PDF.

852
00:41:55,960 --> 00:41:57,960
An operating system does three things.

853
00:41:57,960 --> 00:42:03,840
It defines decision rights, it implements feedback loops, it has enforcement mechanisms.

854
00:42:03,840 --> 00:42:06,320
Decision rights answer, who decides?

855
00:42:06,320 --> 00:42:09,920
At every key boundary, who decides which environments are allowed to exist, who decides

856
00:42:09,920 --> 00:42:14,000
what DLP patterns are acceptable for finance versus HR versus R&D?

857
00:42:14,000 --> 00:42:17,720
Who decides when something is production and must meet stricter criteria?

858
00:42:17,720 --> 00:42:21,400
Who decides which connectors are allowed into a regulated environment?

859
00:42:21,400 --> 00:42:25,640
If the answer to all of those is a committee or it depends, you don't have decision rights,

860
00:42:25,640 --> 00:42:29,920
you have diffusion of responsibility, feedback loops answer, how do we know reality still

861
00:42:29,920 --> 00:42:31,240
matches intent?

862
00:42:31,240 --> 00:42:35,360
That means you're not just setting policies once, you're measuring adherence.

863
00:42:35,360 --> 00:42:37,240
You have metrics for orphaned apps and flows.

864
00:42:37,240 --> 00:42:39,040
You watch DLP violations over time.

865
00:42:39,040 --> 00:42:42,120
You track environment growth relative to actual usage.

866
00:42:42,120 --> 00:42:45,360
You look at the ratio of citizen build assets to incidents.

867
00:42:45,360 --> 00:42:47,760
When thresholds are crossed, something happens.

868
00:42:47,760 --> 00:42:52,120
Enforcement mechanisms answer what actually changes when the system drifts.

869
00:42:52,120 --> 00:42:53,560
Not in theory in practice.

870
00:42:53,560 --> 00:42:57,240
If often flows exceed 2%, who triggers remediation?

871
00:42:57,240 --> 00:43:01,360
If a non-approved connector appears in a production environment who has the authority

872
00:43:01,360 --> 00:43:03,720
to block it and force a review.

873
00:43:03,720 --> 00:43:07,600
If an app crosses a usage threshold that makes it business critical, who can insist

874
00:43:07,600 --> 00:43:10,040
it be onboarded into A-LAM and support?

875
00:43:10,040 --> 00:43:13,640
If you can't answer those questions with concrete names and actions, you don't have an

876
00:43:13,640 --> 00:43:14,880
operating model.

877
00:43:14,880 --> 00:43:16,360
You have governance theatre.

878
00:43:16,360 --> 00:43:20,760
This is where a lot of organisations misunderstand the role of a power platform centre of excellence.

879
00:43:20,760 --> 00:43:22,720
The QE starter kit is a set of tools.

880
00:43:22,720 --> 00:43:24,520
It is not by itself an operating model.

881
00:43:24,520 --> 00:43:28,960
You can have beautiful dashboards, usage reports and maker statistics and still have no

882
00:43:28,960 --> 00:43:30,200
real control.

883
00:43:30,200 --> 00:43:34,640
If you already have a COE but it doesn't look like an operating system, with decision rights,

884
00:43:34,640 --> 00:43:37,560
feedback loops and enforcement, you don't have a governance model.

885
00:43:37,560 --> 00:43:38,560
You have a meeting.

886
00:43:38,560 --> 00:43:41,640
So what does a real power platform governance operating model look like?

887
00:43:41,640 --> 00:43:43,200
First, it is platform team led.

888
00:43:43,200 --> 00:43:45,440
You stand up a platform team whose mandate is clear.

889
00:43:45,440 --> 00:43:47,440
Own standards and guardrails, not every app.

890
00:43:47,440 --> 00:43:48,640
They're not a dev factory.

891
00:43:48,640 --> 00:43:51,360
They don't become a bottleneck for every citizen build form.

892
00:43:51,360 --> 00:43:54,320
Their job is to design and operate the control plane.

893
00:43:54,320 --> 00:43:59,120
Environments, DLP, identity patterns, ALM pipelines, monitoring and metrics.

894
00:43:59,120 --> 00:44:01,520
Second, it organizes policy along three axes.

895
00:44:01,520 --> 00:44:04,760
Scale, how many makers and assets are we talking about?

896
00:44:04,760 --> 00:44:07,440
Sensitivity, what class of data is involved?

897
00:44:07,440 --> 00:44:12,600
Digital internal, confidential regulated, criticality, what is the impact if this app or flow fails?

898
00:44:12,600 --> 00:44:16,960
Annoyance, local disruption, enterprise wide outage, regulatory breach.

899
00:44:16,960 --> 00:44:19,400
Every solution lives somewhere on those three axes.

900
00:44:19,400 --> 00:44:24,480
A personal productivity flow in the default environment is low sensitivity, low criticality,

901
00:44:24,480 --> 00:44:25,480
small scale.

902
00:44:25,480 --> 00:44:31,000
A payments approval app in finance broad is high sensitivity, high criticality and potentially

903
00:44:31,000 --> 00:44:32,000
large scale.

904
00:44:32,000 --> 00:44:34,080
Your operating model doesn't treat those the same.

905
00:44:34,080 --> 00:44:36,080
It defines policy tiers.

906
00:44:36,080 --> 00:44:37,360
Low tier.

907
00:44:37,360 --> 00:44:41,920
Permissive environments with strict DLP around external connectors, limited sharing, lightweight

908
00:44:41,920 --> 00:44:42,920
ownership.

909
00:44:42,920 --> 00:44:48,400
Medium tier, departmental solutions within forced ALM, stronger DLP, clear rakey, high tier,

910
00:44:48,400 --> 00:44:53,200
enterprise or regulated solutions with dedicated environments, locked down connectors, mandatory

911
00:44:53,200 --> 00:44:55,560
life cycle processes and formal sign off.

912
00:44:55,560 --> 00:44:57,520
Third, the operating model runs every day.

913
00:44:57,520 --> 00:45:01,560
It has routines, day to day monitoring of flows, failing in production, weekly reviews

914
00:45:01,560 --> 00:45:05,200
of new production tagged apps crossing usage thresholds.

915
00:45:05,200 --> 00:45:10,440
Currently checks on often assets and DLP violations, quarterly reviews with security and compliance

916
00:45:10,440 --> 00:45:13,160
on regulated environments and AI agents.

917
00:45:13,160 --> 00:45:16,680
The point is simple, governance is not what's written down, governance is what runs.

918
00:45:16,680 --> 00:45:20,080
Once you think of it as an operating system, you can start to design it intentionally.

919
00:45:20,080 --> 00:45:25,600
With a platform team charter, a clear rakey, an environment strategy that maps to data classification

920
00:45:25,600 --> 00:45:31,360
and a time bound plan, day, day 30, day 90, to get from chaos to something you can defend

921
00:45:31,360 --> 00:45:33,560
in front of its seesaw.

922
00:45:33,560 --> 00:45:38,840
Medium team led operating model, charter, rakey, environments, day 30, 90.

923
00:45:38,840 --> 00:45:40,080
So let's make this concrete.

924
00:45:40,080 --> 00:45:44,040
If governance is an operating system, the platform team is the kernel.

925
00:45:44,040 --> 00:45:48,480
Everything else is user land, the platform team charter is simple and non-negotiable.

926
00:45:48,480 --> 00:45:50,160
They own the platform, not every app.

927
00:45:50,160 --> 00:45:51,920
They own standards, patterns and guardrails.

928
00:45:51,920 --> 00:45:55,440
They do not become a ticket queue for please build my form.

929
00:45:55,440 --> 00:45:59,400
Architecturally their responsibilities fall into four buckets, first control plane design.

930
00:45:59,400 --> 00:46:03,120
They define the environment strategy, which environments exist, what they're called,

931
00:46:03,120 --> 00:46:07,560
which security groups map to each one, what data classifications are allowed where,

932
00:46:07,560 --> 00:46:10,440
which DLP policies apply, which regions are used.

933
00:46:10,440 --> 00:46:14,520
They own the baseline conditional access patterns for power platform surfaces.

934
00:46:14,520 --> 00:46:19,040
They decide what managed environment means in your tenant, second patterns in ALM.

935
00:46:19,040 --> 00:46:20,880
They provide reference architectures.

936
00:46:20,880 --> 00:46:24,960
If you're building a departmental approval app, here's the template, here's the pipeline,

937
00:46:24,960 --> 00:46:27,920
here's how you move from dev to test to prod.

938
00:46:27,920 --> 00:46:33,360
They standardize on a small set of ALM patterns, native pipelines, Azure DevOps or GitHub,

939
00:46:33,360 --> 00:46:35,160
and make those the default parts to production.

940
00:46:35,160 --> 00:46:39,000
They don't handcraft every solution, but they define how solutions should behave.

941
00:46:39,000 --> 00:46:40,920
Third, monitoring and metrics.

942
00:46:40,920 --> 00:46:42,360
They own the dashboards.

943
00:46:42,360 --> 00:46:48,440
CoeInventory, DLP Impact Analysis, Environment Health, Flow Failure Rates, often asset percentages,

944
00:46:48,440 --> 00:46:50,600
adoption versus incident ratios.

945
00:46:50,600 --> 00:46:52,440
They set thresholds and wire alerts.

946
00:46:52,440 --> 00:46:55,400
They are the first ones to see when governance starts to drift.

947
00:46:55,400 --> 00:46:57,400
Fourth, enablement and escalation.

948
00:46:57,400 --> 00:47:01,520
They run the maker on boarding experience, the documentation of guard rails, the internal

949
00:47:01,520 --> 00:47:03,040
power platform hub.

950
00:47:03,040 --> 00:47:07,440
They provide guidance sessions, pattern reviews for higher risk solutions, and they act as

951
00:47:07,440 --> 00:47:11,520
the escalation point when something crosses a risk threshold and needs to be pulled into

952
00:47:11,520 --> 00:47:13,040
a stricter regime.

953
00:47:13,040 --> 00:47:16,480
To make that work, you need a clear rarity, business owns data and outcomes.

954
00:47:16,480 --> 00:47:21,040
The platform team owns the platform and patterns, security and compliance own control objectives,

955
00:47:21,040 --> 00:47:24,480
IT operations own support for infrastructure and core services.

956
00:47:24,480 --> 00:47:26,480
So for a given app.

957
00:47:26,480 --> 00:47:29,280
IT is responsible for defining what it does and why it matters.

958
00:47:29,280 --> 00:47:31,520
Business is accountable for the risk of using it.

959
00:47:31,520 --> 00:47:35,560
Platform team is consulted on architecture, environment and DLP fit.

960
00:47:35,560 --> 00:47:38,680
Security and compliance are consulted on regulated scenarios.

961
00:47:38,680 --> 00:47:41,760
IT jobs is informed about support, impact and dependencies.

962
00:47:41,760 --> 00:47:46,200
If your current model makes IT accountable for every low-code asset, you've already lost.

963
00:47:46,200 --> 00:47:49,560
You will either block everything or silently accept risk you don't own.

964
00:47:49,560 --> 00:47:50,560
Now, environments.

965
00:47:50,560 --> 00:47:54,920
You need a minimum viable environment, tearing that aligns to data sensitivity and criticality,

966
00:47:54,920 --> 00:47:55,920
not org chart.

967
00:47:55,920 --> 00:48:00,120
At the bottom, a lockdown default environment scope to personal productivity.

968
00:48:00,120 --> 00:48:01,440
Tied DLP.

969
00:48:01,440 --> 00:48:02,840
No premium connectors.

970
00:48:02,840 --> 00:48:05,120
No business critical data.

971
00:48:05,120 --> 00:48:08,240
Think tell me when my manager emails me, not run payroll.

972
00:48:08,240 --> 00:48:12,720
Then non-regulated dev test prod tiers for departmental and enterprise apps.

973
00:48:12,720 --> 00:48:14,280
Names that actually mean something.

974
00:48:14,280 --> 00:48:18,280
Depth dev, depth test, depth prod, enterprise prod.

975
00:48:18,280 --> 00:48:22,120
Each with its own DLP policy, security groups and ALM pipelines.

976
00:48:22,120 --> 00:48:23,160
Production is invitation only.

977
00:48:23,160 --> 00:48:25,360
You don't accidentally land there.

978
00:48:25,360 --> 00:48:28,440
Alongside that, restricted or regulated environments.

979
00:48:28,440 --> 00:48:32,080
Finance reg, PHI restricted, client sensitive.

980
00:48:32,080 --> 00:48:34,880
These are mapped explicitly to data classifications.

981
00:48:34,880 --> 00:48:36,520
Only certain connectors are allowed.

982
00:48:36,520 --> 00:48:38,120
Only certain roles exist.

983
00:48:38,120 --> 00:48:41,680
Every asset there is, by definition, in scope for audit.

984
00:48:41,680 --> 00:48:43,120
Environment creation is not a free for all.

985
00:48:43,120 --> 00:48:47,440
It's a controlled operation run by the platform team, ideally automated with requests and approvals

986
00:48:47,440 --> 00:48:50,480
that capture purpose owner and expect a data class.

987
00:48:50,480 --> 00:48:51,680
That's the steady state.

988
00:48:51,680 --> 00:48:53,320
How do you get there from where you are?

989
00:48:53,320 --> 00:48:55,560
You use a day, day 30, day 90 plan.

990
00:48:55,560 --> 00:48:56,560
Day is the freeze.

991
00:48:56,560 --> 00:48:57,560
You don't fix everything.

992
00:48:57,560 --> 00:48:58,560
You stop it getting worse.

993
00:48:58,560 --> 00:49:02,480
You freeze ad hoc environment creation and switch it to admin only.

994
00:49:02,480 --> 00:49:06,560
You define at least roughly which existing environments are prod, which are dev test and

995
00:49:06,560 --> 00:49:08,120
which are unknown.

996
00:49:08,120 --> 00:49:12,360
You deploy a baseline tenant-wide DLP policy that blocks the worst consumer connectors in

997
00:49:12,360 --> 00:49:14,080
all but the default environment.

998
00:49:14,080 --> 00:49:15,840
You turn on audit logging where it's off.

999
00:49:15,840 --> 00:49:19,080
You identify the top end production looking environments by usage.

1000
00:49:19,080 --> 00:49:20,480
The goal for day is simple.

1001
00:49:20,480 --> 00:49:21,720
Reduce the rate of new entropy.

1002
00:49:21,720 --> 00:49:22,880
Day 30 is structure.

1003
00:49:22,880 --> 00:49:24,880
You stand up or formalize the platform team.

1004
00:49:24,880 --> 00:49:29,440
You publish a first pass environment strategy and map existing environments into it.

1005
00:49:29,440 --> 00:49:34,120
You define and socialize the right C and the rule no owner is no app in prod.

1006
00:49:34,120 --> 00:49:38,720
You deploy at least one standard ALM pattern and apply it to net new high-criticality solutions.

1007
00:49:38,720 --> 00:49:41,160
You get the COE or equivalent telemetry running.

1008
00:49:41,160 --> 00:49:44,760
If it isn't already, you don't have all the answers by day 30 but you've drawn the map.

1009
00:49:44,760 --> 00:49:46,560
Day 90 is enforcement.

1010
00:49:46,560 --> 00:49:50,000
You start enforcing lifecycle management for production environments.

1011
00:49:50,000 --> 00:49:52,480
Review often assets, decommission or reassign.

1012
00:49:52,480 --> 00:49:56,960
You apply DLP policies per environment tier instead of one giant inconsistent blob.

1013
00:49:56,960 --> 00:50:01,200
You publish metrics, often flow percentage DLP violations environment growth.

1014
00:50:01,200 --> 00:50:02,920
You wire alerts to real people.

1015
00:50:02,920 --> 00:50:08,120
You also make your first firm decision on AI governance, which environments can use co-pilot.

1016
00:50:08,120 --> 00:50:12,520
What tagging, logging and review are mandatory for AI assisted assets.

1017
00:50:12,520 --> 00:50:15,520
How prompts are treated from a privacy perspective.

1018
00:50:15,520 --> 00:50:17,440
By day 90 you're not done.

1019
00:50:17,440 --> 00:50:21,400
But you've moved from accidental behavior to an operating model.

1020
00:50:21,400 --> 00:50:23,760
You can stand in front of a CISO and defend.

1021
00:50:23,760 --> 00:50:26,360
And the rule that underpins all of it stays simple.

1022
00:50:26,360 --> 00:50:30,720
If the platform matters enough to worry about its security, it matters enough to have a platform

1023
00:50:30,720 --> 00:50:33,880
team running a real operating model.

1024
00:50:33,880 --> 00:50:37,400
Metrics that matter, turning governance into a measurable system.

1025
00:50:37,400 --> 00:50:39,440
At this point there's a predictable objection.

1026
00:50:39,440 --> 00:50:43,800
Okay, platform team, environments, DLP, ownership, day 3090.

1027
00:50:43,800 --> 00:50:46,200
How do we know if any of this is actually working?

1028
00:50:46,200 --> 00:50:49,400
If you can't answer that with numbers, you're not running governance.

1029
00:50:49,400 --> 00:50:50,760
You're running theatre.

1030
00:50:50,760 --> 00:50:53,400
Metrics without metrics is just well phrased intent.

1031
00:50:53,400 --> 00:50:57,160
So what does it mean to treat power platform governance as a measurable system?

1032
00:50:57,160 --> 00:50:59,880
If you remember one thing from this section, make it this.

1033
00:50:59,880 --> 00:51:01,520
Metrics only matter if they drive action.

1034
00:51:01,520 --> 00:51:03,120
It starts with one principle.

1035
00:51:03,120 --> 00:51:06,400
You cannot steer what you do not measure and you should not measure what you're not prepared

1036
00:51:06,400 --> 00:51:07,400
to act on.

1037
00:51:07,400 --> 00:51:11,040
So the first job of the platform team is not to build pretty a dashboards.

1038
00:51:11,040 --> 00:51:15,280
It's to define a small brutal set of metrics that connect directly to control.

1039
00:51:15,280 --> 00:51:16,520
Think of three categories.

1040
00:51:16,520 --> 00:51:18,640
Hygiene.risk.scale.

1041
00:51:18,640 --> 00:51:21,280
Hygiene metrics tell you whether the basics are under control.

1042
00:51:21,280 --> 00:51:23,760
The most important one is often assets.

1043
00:51:23,760 --> 00:51:26,920
Apps and flows in production environments with no valid business owner.

1044
00:51:26,920 --> 00:51:30,880
You measure it as a percentage of total production assets and you set a hard threshold.

1045
00:51:30,880 --> 00:51:35,960
For example, if more than 2% of production flows or apps are often remediation is mandatory.

1046
00:51:35,960 --> 00:51:38,680
Mandatory means three things actually happen.

1047
00:51:38,680 --> 00:51:40,600
Platform team initiates remediation.

1048
00:51:40,600 --> 00:51:44,480
They generate the list, open tickets and drive the process.

1049
00:51:44,480 --> 00:51:45,880
Business owner resolves.

1050
00:51:45,880 --> 00:51:50,920
They either accept ownership, nominate a new owner or approve decommissioning.

1051
00:51:50,920 --> 00:51:51,920
Security validates.

1052
00:51:51,920 --> 00:51:55,840
They confirm that anything decommissioned or reassigned doesn't leave residual access or

1053
00:51:55,840 --> 00:51:56,840
data behind.

1054
00:51:56,840 --> 00:51:57,840
That chain matters.

1055
00:51:57,840 --> 00:52:02,560
Metrics without a clear who moves first, who closes, who checks, degrade into noise.

1056
00:52:02,560 --> 00:52:04,920
The second hygiene metric is DLP violations.

1057
00:52:04,920 --> 00:52:08,720
How many flows or apps attempt to use blocked connector combinations and how quickly are

1058
00:52:08,720 --> 00:52:09,720
those violations resolved?

1059
00:52:09,720 --> 00:52:11,200
You don't just count violations.

1060
00:52:11,200 --> 00:52:12,480
You put an SLA on them.

1061
00:52:12,480 --> 00:52:15,680
For example, critical DLP violations in production.

1062
00:52:15,680 --> 00:52:20,960
Anything involving regulated data or high-risk connectors must be triaged within 4 hours

1063
00:52:20,960 --> 00:52:24,400
and either remediated or formally accepted within 24.

1064
00:52:24,400 --> 00:52:27,440
Again, with ownership, platform team detects and classifies.

1065
00:52:27,440 --> 00:52:31,000
Business owner decides whether the attempted pattern is legitimate.

1066
00:52:31,000 --> 00:52:34,440
Security approves or rejects the pattern and updates policy if needed.

1067
00:52:34,440 --> 00:52:35,440
Now risk metrics.

1068
00:52:35,440 --> 00:52:38,960
Here you care less about raw counts and more about ratios and trends.

1069
00:52:38,960 --> 00:52:42,120
One useful metric is adoption versus incident ratio.

1070
00:52:42,120 --> 00:52:46,160
For a given time period, how many net new production apps and flows went live and how many governance

1071
00:52:46,160 --> 00:52:47,800
incidents occurred?

1072
00:52:47,800 --> 00:52:51,640
Incidents meaning unauthorized data movement access escalation audit findings tied to power

1073
00:52:51,640 --> 00:52:54,640
platform or material outages from low-code assets.

1074
00:52:54,640 --> 00:53:00,200
If your ratio is say 200 new production solutions and one minor incident per quarter, that's

1075
00:53:00,200 --> 00:53:01,200
one story.

1076
00:53:01,200 --> 00:53:04,760
If it's 50 solutions and five significant incidents, that's another.

1077
00:53:04,760 --> 00:53:09,440
You're measuring not just how much you build but how safely you're operating at that speed.

1078
00:53:09,440 --> 00:53:11,920
Another risk metric is environment growth rate.

1079
00:53:11,920 --> 00:53:17,160
How many environments do you have by tier, personal departmental enterprise regulated and how fast

1080
00:53:17,160 --> 00:53:18,640
is that number changing?

1081
00:53:18,640 --> 00:53:22,360
You might set a guardrail like net growth in production and regulated environments should

1082
00:53:22,360 --> 00:53:25,200
not exceed 10% per quarter without review.

1083
00:53:25,200 --> 00:53:30,040
Above that, the platform team and security sit down and ask, are we seeing environment proliferation

1084
00:53:30,040 --> 00:53:31,960
as a proxy for missing patterns?

1085
00:53:31,960 --> 00:53:34,720
Again, the metric is only useful if it triggers action.

1086
00:53:34,720 --> 00:53:38,920
A growth spike might mean you need new standardized environment types or that a particular

1087
00:53:38,920 --> 00:53:42,560
business unit is treating environments as disposable sandboxes.

1088
00:53:42,560 --> 00:53:44,560
Finally, scale metrics.

1089
00:53:44,560 --> 00:53:48,680
You want to understand where citizen development is actually happening and whether it's distributed

1090
00:53:48,680 --> 00:53:49,680
in the same way.

1091
00:53:49,680 --> 00:53:54,280
The COE dashboards can show you makers by business unit, asset counts by environment and usage

1092
00:53:54,280 --> 00:53:55,280
by app.

1093
00:53:55,280 --> 00:53:58,720
You can convert that into something actionable, percentage of business units with at least

1094
00:53:58,720 --> 00:54:03,200
one active maker, top 10 environments by usage and their own equality.

1095
00:54:03,200 --> 00:54:04,960
Distribution of makers versus apps.

1096
00:54:04,960 --> 00:54:09,360
Do you have a healthy maker community or a handful of heroes carrying everything?

1097
00:54:09,360 --> 00:54:12,920
You combine those with your hygiene and risk metrics to decide where to invest in ablment

1098
00:54:12,920 --> 00:54:14,680
versus where to tighten controls.

1099
00:54:14,680 --> 00:54:17,240
All of this is easily built with existing tools.

1100
00:54:17,240 --> 00:54:20,440
The COE starter kit already collects most of the raw data.

1101
00:54:20,440 --> 00:54:24,680
You can build power BI reports that show inventory by environment, risk heat maps across

1102
00:54:24,680 --> 00:54:29,120
sensitivity, owner quality and usage and trend lines over time.

1103
00:54:29,120 --> 00:54:30,520
The trick is restrained.

1104
00:54:30,520 --> 00:54:31,960
You do not need 40 metrics.

1105
00:54:31,960 --> 00:54:36,160
You need a short list that an executive can understand on one slide and that your platform

1106
00:54:36,160 --> 00:54:37,840
team can drive every week.

1107
00:54:37,840 --> 00:54:43,440
For example, a minimal governance scorecard might be "offent production assets" - 1, 2%,

1108
00:54:43,440 --> 00:54:45,560
target, 2%.

1109
00:54:45,560 --> 00:54:50,440
Critical DLP violations resolved within 24 hours - 96% target, 100%.

1110
00:54:50,440 --> 00:54:55,560
Net production regulated environment growth - 7% target, intuous and 10% - adoption versus

1111
00:54:55,560 --> 00:55:00,160
incident ratio - 150.1, target, 1, 101.

1112
00:55:00,160 --> 00:55:04,920
Business units with active makers - 80%, target, and 70%.

1113
00:55:04,920 --> 00:55:08,880
Each of those has a named owner and a defined next step when it drifts.

1114
00:55:08,880 --> 00:55:13,720
When the offent percentage crosses 2%, platform opens remediation, business resolves, security

1115
00:55:13,720 --> 00:55:14,720
validates.

1116
00:55:14,720 --> 00:55:19,680
When DLP-SLA drops, platform reviews the patterns, business justifies or retires, security

1117
00:55:19,680 --> 00:55:21,880
titans or just policy.

1118
00:55:21,880 --> 00:55:26,720
When environment growth spikes platform freezes new creation in that tier until they understand

1119
00:55:26,720 --> 00:55:27,720
the driver.

1120
00:55:27,720 --> 00:55:30,280
This means to turn governance into a measurable system.

1121
00:55:30,280 --> 00:55:33,760
You're no longer arguing about whether you feel in control of power platform.

1122
00:55:33,760 --> 00:55:37,960
You can point to a small set of numbers, that track hygiene, risk and scale, and to the

1123
00:55:37,960 --> 00:55:41,160
routines that move those numbers in the right direction.

1124
00:55:41,160 --> 00:55:44,520
And once you have that, you can finally have the same conversation about zero trust in

1125
00:55:44,520 --> 00:55:48,400
low-code because you're no longer guessing how the system behaves, you're measuring

1126
00:55:48,400 --> 00:55:49,720
how it drifts.

1127
00:55:49,720 --> 00:55:53,000
Zero trust meets low-code, designing for conditional chaos.

1128
00:55:53,000 --> 00:55:56,160
Zero trust gets thrown around so much it's almost background noise.

1129
00:55:56,160 --> 00:55:57,160
Verify explicitly.

1130
00:55:57,160 --> 00:55:58,440
Use least privilege.

1131
00:55:58,440 --> 00:55:59,920
Assume breach.

1132
00:55:59,920 --> 00:56:00,920
Pause here.

1133
00:56:00,920 --> 00:56:04,880
This is where most zero trust slideware falls apart when it hits a low-code platform.

1134
00:56:04,880 --> 00:56:09,880
The problem is that most zero trust conversations are about network edges and classic applications,

1135
00:56:09,880 --> 00:56:14,640
not about a distributed citizen-driven, low-code platform that can change shape every day.

1136
00:56:14,640 --> 00:56:15,800
Power platform is exactly that.

1137
00:56:15,800 --> 00:56:20,360
A distributed decision engine that keeps evolving, which means if you don't design for zero

1138
00:56:20,360 --> 00:56:21,960
trust here, you don't have it anywhere.

1139
00:56:21,960 --> 00:56:25,680
So let's translate those three principles into the reality of apps, flows, environments

1140
00:56:25,680 --> 00:56:26,960
and connectors.

1141
00:56:26,960 --> 00:56:29,680
And into the conditional chaos we talked about earlier.

1142
00:56:29,680 --> 00:56:32,760
Start with verify explicitly.

1143
00:56:32,760 --> 00:56:35,160
In the power platform world, that means two things.

1144
00:56:35,160 --> 00:56:36,960
Entra conditional access and environment routing.

1145
00:56:36,960 --> 00:56:40,880
And you're not just deciding whether a user can sign in, you're deciding from where, on

1146
00:56:40,880 --> 00:56:44,720
what, into which environment and with what blast radius.

1147
00:56:44,720 --> 00:56:46,480
So you establish clear patterns.

1148
00:56:46,480 --> 00:56:50,400
Personal productivity lives in the default or personal dev environments behind stricter

1149
00:56:50,400 --> 00:56:53,680
DLP and with no access to regulated data.

1150
00:56:53,680 --> 00:56:58,440
And enterprise apps live in named dev test, prod environments, each backed by

1151
00:56:58,440 --> 00:56:59,800
andro security groups.

1152
00:56:59,800 --> 00:57:03,800
Regulated workloads live only in restricted environments where access requires compliant

1153
00:57:03,800 --> 00:57:07,920
devices, strong MFA and maybe even network location controls.

1154
00:57:07,920 --> 00:57:11,440
Environment routing and groups turn that into a deterministic pattern instead of an honor

1155
00:57:11,440 --> 00:57:12,440
system.

1156
00:57:12,440 --> 00:57:15,280
When a maker shows up, they don't land in the global sandbox.

1157
00:57:15,280 --> 00:57:17,520
They land where their persona says they belong.

1158
00:57:17,520 --> 00:57:20,000
Then use least privilege.

1159
00:57:20,000 --> 00:57:24,320
In low code, least privilege is less about individual tables and more about patterns.

1160
00:57:24,320 --> 00:57:28,960
You avoid maker as owner of everything designs where the same human account owns the

1161
00:57:28,960 --> 00:57:33,280
dataverse environment, the apps, the flows, the custom connectors and the azure bits.

1162
00:57:33,280 --> 00:57:36,880
You push ownership to service principles and managed identities where appropriate.

1163
00:57:36,880 --> 00:57:41,000
You design dataverse roles per persona instead of everyone gets basic user plus a few

1164
00:57:41,000 --> 00:57:42,120
random grounds.

1165
00:57:42,120 --> 00:57:45,120
You also implement least privilege at the connector level.

1166
00:57:45,120 --> 00:57:48,720
That means standard DLP sets like a core business set.

1167
00:57:48,720 --> 00:57:52,520
Serververse, SharePoint, Exchange, First Party, Line of Business APIs.

1168
00:57:52,520 --> 00:57:54,000
A collaboration set.

1169
00:57:54,000 --> 00:57:57,480
Teams, planner, certain external SaaS apps that have been risk assessed.

1170
00:57:57,480 --> 00:58:01,520
A high-risk set, consumer email, personal storage, generic HDDP.

1171
00:58:01,520 --> 00:58:04,640
You don't let a single app or flow span all three sets.

1172
00:58:04,640 --> 00:58:09,000
If a solution truly needs to bridge them, it becomes an exception with explicit review.

1173
00:58:09,000 --> 00:58:10,000
Not a default.

1174
00:58:10,000 --> 00:58:11,480
Now the uncomfortable one.

1175
00:58:11,480 --> 00:58:12,480
Assume breach.

1176
00:58:12,480 --> 00:58:14,160
Assume a connector is compromised.

1177
00:58:14,160 --> 00:58:16,120
Assume a maker account is fished.

1178
00:58:16,120 --> 00:58:17,600
Assume flow is misconfigured.

1179
00:58:17,600 --> 00:58:18,600
What happens?

1180
00:58:18,600 --> 00:58:20,600
Zero trust-aware power platform design.

1181
00:58:20,600 --> 00:58:22,680
DLP is not just a compliance box.

1182
00:58:22,680 --> 00:58:24,360
It's your containment boundary.

1183
00:58:24,360 --> 00:58:28,920
If a compromised maker account can only build in a departmental dev environment with no

1184
00:58:28,920 --> 00:58:32,840
access to finance or PHI connectors, your blast radius is small.

1185
00:58:32,840 --> 00:58:36,200
If the only place that talks to external SaaS is a dedicated integration environment with

1186
00:58:36,200 --> 00:58:40,080
tightly-scoped service principles, you've limited exfiltration paths.

1187
00:58:40,080 --> 00:58:42,720
Audit logging and monitoring become your forensic backbone.

1188
00:58:42,720 --> 00:58:46,840
You make sure every regulated environment has dataverse auditing turned on for key tables

1189
00:58:46,840 --> 00:58:48,000
and fields.

1190
00:58:48,000 --> 00:58:52,080
You root power apps and power automate events into purview or your CM.

1191
00:58:52,080 --> 00:58:56,120
You use the COE telemetry not just for adoption metrics but for anomaly detection.

1192
00:58:56,120 --> 00:58:58,080
Sudden spikes in connector usage.

1193
00:58:58,080 --> 00:59:01,720
Flow is calling unusual endpoints, new environments with strange naming.

1194
00:59:01,720 --> 00:59:04,200
And here's where conditional chaos comes back.

1195
00:59:04,200 --> 00:59:08,080
Zero trust collapses if your patents are opaque, bespoke and constantly changing.

1196
00:59:08,080 --> 00:59:11,800
Too many one-off conditional access rules, too many custom security roles, too many special

1197
00:59:11,800 --> 00:59:15,640
environments, and you've built a system no human can reason about.

1198
00:59:15,640 --> 00:59:18,640
So the real zero trust move in low code is simplification.

1199
00:59:18,640 --> 00:59:20,240
Fewer clearer environment types.

1200
00:59:20,240 --> 00:59:22,240
Fewer standardized DLP sets.

1201
00:59:22,240 --> 00:59:24,720
Fewer well-defined role bundles and make up personas.

1202
00:59:24,720 --> 00:59:27,120
You trade some flexibility for predictability.

1203
00:59:27,120 --> 00:59:31,680
That might mean you say no to yet another special environment and instead refine an existing

1204
00:59:31,680 --> 00:59:32,680
pattern.

1205
00:59:32,680 --> 00:59:36,240
It might mean you collapse a sprawl of subtly different roles into three or four well-designed

1206
00:59:36,240 --> 00:59:37,240
ones.

1207
00:59:37,240 --> 00:59:41,320
It might mean you route all regulated workloads through a small number of heavily instrumented

1208
00:59:41,320 --> 00:59:45,160
managed environments instead of sprinkling sensitivity everywhere.

1209
00:59:45,160 --> 00:59:48,040
This is designed philosophy, not configuration trivia.

1210
00:59:48,040 --> 00:59:51,120
You're not trying to memorize every toggle in the admin center.

1211
00:59:51,120 --> 00:59:54,560
You're trying to enforce a small number of architectural truths.

1212
00:59:54,560 --> 00:59:57,320
Identities are verified and segmented by persona.

1213
00:59:57,320 --> 00:59:59,480
Data parts are controlled by environment and DLP.

1214
00:59:59,480 --> 01:00:02,200
Blast radius is limited by design, not by luck.

1215
01:00:02,200 --> 01:00:06,200
Behavior is observable enough that when, not if something odd happens, you can see it

1216
01:00:06,200 --> 01:00:07,440
and respond.

1217
01:00:07,440 --> 01:00:11,320
Once you understand that, adding co-pilot and AI into the mix stops being magic and

1218
01:00:11,320 --> 01:00:15,640
starts being just another category of identity and data flow you have to constrain.

1219
01:00:15,640 --> 01:00:20,640
And that's the point you need to reach before you start treating AI as just more productivity

1220
01:00:20,640 --> 01:00:23,040
on top of conditional chaos.

1221
01:00:23,040 --> 01:00:25,760
Co-pilot AI and the next wave of governance pressure.

1222
01:00:25,760 --> 01:00:29,280
Everything we've talked about so far was already true before AI showed up in Power Platform.

1223
01:00:29,280 --> 01:00:31,240
Co-pilot doesn't change the laws of this system.

1224
01:00:31,240 --> 01:00:34,400
It just removes the friction that was slowing those laws down.

1225
01:00:34,400 --> 01:00:37,640
So you have to start with a simple, slightly brutal assumption.

1226
01:00:37,640 --> 01:00:39,760
Whatever your governance posture is today.

1227
01:00:39,760 --> 01:00:42,400
Data-based and agentic AI will accelerate it.

1228
01:00:42,400 --> 01:00:46,960
If your control plane is clear, measured and enforced, co-pilot accelerates value.

1229
01:00:46,960 --> 01:00:51,440
If your control plane is opaque, ad hoc and full of entropy generators, co-pilot accelerates

1230
01:00:51,440 --> 01:00:56,480
failure, architecturally co-pilot adds three new pressures, first, asset creation speed.

1231
01:00:56,480 --> 01:01:00,960
Makers no longer have to understand every nuance of power effects or dataverse schema design.

1232
01:01:00,960 --> 01:01:05,040
They can say, "Build me a case management app with these fields and co-pilot scaffold something

1233
01:01:05,040 --> 01:01:10,120
workable." They can say, "Generator flow that notifies me when X happens and the platform

1234
01:01:10,120 --> 01:01:14,600
fills in the steps." That means the rate at which new apps and flows appear in your tenant

1235
01:01:14,600 --> 01:01:17,400
increases even if the number of human makers doesn't.

1236
01:01:17,400 --> 01:01:21,520
The traditional signals you relied on, who's in the maker community, who's requesting

1237
01:01:21,520 --> 01:01:26,320
environments, become lagging indicators, second, opaque intent.

1238
01:01:26,320 --> 01:01:30,680
With human build solutions, however messy you can at least ask the maker what they intended.

1239
01:01:30,680 --> 01:01:34,800
With AI assisted solutions, the intent is split across a human prompt and an AI models

1240
01:01:34,800 --> 01:01:35,800
interpretation.

1241
01:01:35,800 --> 01:01:39,720
If you don't log prompts, if you don't tag AI generated assets, if you don't capture

1242
01:01:39,720 --> 01:01:44,240
which co-pilots were used where, you lose the ability to reason about why a given app or

1243
01:01:44,240 --> 01:01:46,600
flow exists and what it was meant to do.

1244
01:01:46,600 --> 01:01:48,480
Third, blended authorship.

1245
01:01:48,480 --> 01:01:53,680
In most enterprises you will not have pure AI solutions or pure human solutions.

1246
01:01:53,680 --> 01:01:54,680
You will have hybrids.

1247
01:01:54,680 --> 01:01:57,200
A human starts something, co-pilot suggests formulas.

1248
01:01:57,200 --> 01:01:58,600
The human tweaks them.

1249
01:01:58,600 --> 01:02:00,880
Another co-pilot refactors a flow later.

1250
01:02:00,880 --> 01:02:03,960
Over time the boundary between human and AI authorship blurs.

1251
01:02:03,960 --> 01:02:07,560
That's why treating AI as a novelty feature is dangerous.

1252
01:02:07,560 --> 01:02:11,800
Governance has to treat AI as a new category of identity and behavior in the system.

1253
01:02:11,800 --> 01:02:15,080
So what does a sane co-pilot governance stance look like?

1254
01:02:15,080 --> 01:02:16,360
First, default restrict.

1255
01:02:16,360 --> 01:02:18,000
Don't default allow.

1256
01:02:18,000 --> 01:02:21,920
Co-pilot capabilities in power apps, power automate and co-pilot studio should be enabled

1257
01:02:21,920 --> 01:02:24,960
first in a small set of well understood environments.

1258
01:02:24,960 --> 01:02:28,960
Ideally non-regulated, dev test tiers with good telemetry.

1259
01:02:28,960 --> 01:02:33,080
You do not start by sprinkling AI across every environment where you already struggle to

1260
01:02:33,080 --> 01:02:34,080
see what's happening.

1261
01:02:34,080 --> 01:02:36,480
Second, mandatory tagging and logging.

1262
01:02:36,480 --> 01:02:39,160
Every AI assisted asset needs to declare itself.

1263
01:02:39,160 --> 01:02:43,160
That can be as simple as a solution level flag or a naming convention that's enforced by

1264
01:02:43,160 --> 01:02:45,680
the platform team, but it must exist.

1265
01:02:45,680 --> 01:02:49,440
You should be able to answer from the admin center or your COE dashboards, which apps,

1266
01:02:49,440 --> 01:02:53,280
flows and agents were created or significantly modified with co-pilot.

1267
01:02:53,280 --> 01:02:54,800
In which environments do they live?

1268
01:02:54,800 --> 01:02:56,600
Who is the accountable business owner for each?

1269
01:02:56,600 --> 01:02:59,560
On top of that, prompt logging becomes part of your forensic toolkit.

1270
01:02:59,560 --> 01:03:02,000
No, you don't need to hold every prompt forever.

1271
01:03:02,000 --> 01:03:06,280
And for regulated workloads, you do need an audit trail that shows what kinds of instructions

1272
01:03:06,280 --> 01:03:09,080
were given to AI when building or operating a solution.

1273
01:03:09,080 --> 01:03:10,840
That's not about spying on makers.

1274
01:03:10,840 --> 01:03:14,400
It's about being able to explain behavior after the fact.

1275
01:03:14,400 --> 01:03:18,240
Third, AI-specific DLP and connector rules.

1276
01:03:18,240 --> 01:03:22,520
Co-pilot is just another client of your data, but it's a client that can connect things

1277
01:03:22,520 --> 01:03:24,120
humans wouldn't think to connect.

1278
01:03:24,120 --> 01:03:28,080
You need to be explicit about where AI can read from and where it can write to.

1279
01:03:28,080 --> 01:03:31,880
For example, co-pilot can read from internal knowledge bases, approved

1280
01:03:31,880 --> 01:03:35,720
SharePoint sites and data verse tables tagged as internal.

1281
01:03:35,720 --> 01:03:40,200
Co-pilot cannot read directly from PHI or high sensitivity financial data without going

1282
01:03:40,200 --> 01:03:43,640
through a controlled agent in a restricted environment.

1283
01:03:43,640 --> 01:03:48,280
Co-pilot cannot write to external mailboxes, consumer storage or public facing lists

1284
01:03:48,280 --> 01:03:50,080
without a human in the loop review.

1285
01:03:50,080 --> 01:03:51,400
Those aren't product checkboxes.

1286
01:03:51,400 --> 01:03:53,800
They're DLP patterns and environment choices.

1287
01:03:53,800 --> 01:03:56,480
Finally, treat AI agents as non-human identities.

1288
01:03:56,480 --> 01:04:00,880
From an Entra and Power Platform perspective, an agent is just another principle-making

1289
01:04:00,880 --> 01:04:02,720
decisions and calling APIs.

1290
01:04:02,720 --> 01:04:07,080
So you give it the same rigor you would a service principle, least privilege access, clear

1291
01:04:07,080 --> 01:04:11,760
scoping to specific environments and data classes, auditable activity trails, explicit

1292
01:04:11,760 --> 01:04:14,400
life cycle, how it's created, reviewed, retired.

1293
01:04:14,400 --> 01:04:18,120
If you're not doing that, you're effectively giving root access to an opaque piece of logic

1294
01:04:18,120 --> 01:04:21,840
that can act faster than any human and hide inside normal traffic.

1295
01:04:21,840 --> 01:04:25,040
And keep this sentence in mind when the AI hype gets loud.

1296
01:04:25,040 --> 01:04:27,760
Most co-pilot failures will not look like AI failures.

1297
01:04:27,760 --> 01:04:30,760
They will look like ordinary governance failures or just faster.

1298
01:04:30,760 --> 01:04:35,840
The wrong environment, the wrong connectors, no owner, no life cycle, no metrics.

1299
01:04:35,840 --> 01:04:38,880
Co-pilot just gets you to the failure state in days instead of months.

1300
01:04:38,880 --> 01:04:43,200
So if your low-code governance framework cannot handle humans, it will not handle agents.

1301
01:04:43,200 --> 01:04:48,040
Fix the framework first, then let AI amplify something you're willing to scale.

1302
01:04:48,040 --> 01:04:49,720
The blunt answer and the real risk.

1303
01:04:49,720 --> 01:04:51,040
So here's the blunt answer.

1304
01:04:51,040 --> 01:04:54,480
Yes, Microsoft Power Platform is secure enough for serious enterprise use.

1305
01:04:54,480 --> 01:04:57,400
The real risk lives in your governance, not in the platform.

1306
01:04:57,400 --> 01:04:59,160
The Power Platform doesn't create risk.

1307
01:04:59,160 --> 01:05:02,360
It reveals whether your enterprise is governable at speed.

1308
01:05:02,360 --> 01:05:07,120
If you want that answer to be yes, treat Power Platform as a product with a platform team,

1309
01:05:07,120 --> 01:05:11,600
implement a 90-day governance plan, wire in metrics, and stop enabling co-pilot in production

1310
01:05:11,600 --> 01:05:14,320
without clear environments, DLP, ownership and review.