The Governance Illusion: Why Your Tenant Is Beyond Control

1
00:00:00,000 --> 00:00:03,080
Most organizations believe Microsoft 365 governance

2
00:00:03,080 --> 00:00:04,520
is something they do.

3
00:00:04,520 --> 00:00:05,460
They are wrong.

4
00:00:05,460 --> 00:00:08,320
Governance is something that either keeps happening every day

5
00:00:08,320 --> 00:00:10,560
or quietly stops the moment the project ends.

6
00:00:10,560 --> 00:00:13,480
And Microsoft 365 isn't a product you finish configuring.

7
00:00:13,480 --> 00:00:16,080
It's an ecosystem that keeps creating new surfaces,

8
00:00:16,080 --> 00:00:19,040
teams, sites, apps, flows, agents,

9
00:00:19,040 --> 00:00:20,280
whether you're ready or not.

10
00:00:20,280 --> 00:00:22,720
Today, we're going to strip away the illusion

11
00:00:22,720 --> 00:00:25,360
why policy existing doesn't mean policy is enforced,

12
00:00:25,360 --> 00:00:27,800
why compliant doesn't mean controlled.

13
00:00:27,800 --> 00:00:29,600
And what predictable control looks like

14
00:00:29,600 --> 00:00:32,200
when nobody's selling you a fairytale.

15
00:00:32,200 --> 00:00:35,560
The foundational misunderstanding, configuration isn't control.

16
00:00:35,560 --> 00:00:37,280
The foundational mistake is simple.

17
00:00:37,280 --> 00:00:39,480
You think governance is a set of settings.

18
00:00:39,480 --> 00:00:40,240
It isn't?

19
00:00:40,240 --> 00:00:42,000
Configuration is what you told the platform

20
00:00:42,000 --> 00:00:43,440
to do on a Tuesday afternoon.

21
00:00:43,440 --> 00:00:45,760
Control is what the platform does on a Friday night

22
00:00:45,760 --> 00:00:47,240
when a contractor shares a folder,

23
00:00:47,240 --> 00:00:50,000
a maker publishes a flow, and a new copilot feature

24
00:00:50,000 --> 00:00:52,080
rolls out with defaults you didn't review.

25
00:00:52,080 --> 00:00:54,320
That distinction matters because Microsoft 365

26
00:00:54,320 --> 00:00:55,640
is not a static system.

27
00:00:55,640 --> 00:00:57,360
It is a distributed decision engine.

28
00:00:57,360 --> 00:00:59,760
It makes thousands of authorization decisions

29
00:00:59,760 --> 00:01:03,320
across workloads every day with fragmented context.

30
00:01:03,320 --> 00:01:05,080
Entra evaluates identity signals,

31
00:01:05,080 --> 00:01:08,080
SharePoint evaluates link types and site permissions.

32
00:01:08,080 --> 00:01:10,200
Teams adds its own membership and channel permission

33
00:01:10,200 --> 00:01:13,000
topology, Power Platform evaluates connectors,

34
00:01:13,000 --> 00:01:15,080
Environment boundaries, and which identity

35
00:01:15,080 --> 00:01:16,640
is actually executing the thing.

36
00:01:16,640 --> 00:01:18,920
Then copilot shows up and queries across whatever

37
00:01:18,920 --> 00:01:20,040
those decisions allow.

38
00:01:20,040 --> 00:01:22,160
You can't configure your way out of that.

39
00:01:22,160 --> 00:01:24,520
Now here's where most people mess up.

40
00:01:24,520 --> 00:01:26,960
They confuse intent with configuration

41
00:01:26,960 --> 00:01:28,600
and configuration with behavior.

42
00:01:28,600 --> 00:01:31,080
Intent is what you think the organization means.

43
00:01:31,080 --> 00:01:32,920
Only owners should invite guests.

44
00:01:32,920 --> 00:01:36,920
Zezen is so much so sent in, so is sensitive content

45
00:01:36,920 --> 00:01:38,600
shouldn't be broadly accessible.

46
00:01:38,600 --> 00:01:41,200
Flows shouldn't send data to personal email.

47
00:01:41,200 --> 00:01:42,320
Intent is human.

48
00:01:42,320 --> 00:01:45,000
It lives in policy documents, architecture diagrams,

49
00:01:45,000 --> 00:01:47,440
and the sentence we would never allow that.

50
00:01:47,440 --> 00:01:49,520
Configuration is the translation layer.

51
00:01:49,520 --> 00:01:51,000
It is brittle, it is partial,

52
00:01:51,000 --> 00:01:53,960
it is frequently inconsistent across workloads,

53
00:01:53,960 --> 00:01:57,520
and it is often implemented by copying a recommendation,

54
00:01:57,520 --> 00:01:59,640
applying it tenant-wide, and then discovering

55
00:01:59,640 --> 00:02:02,200
the business breaks, therefore exceptions appear.

56
00:02:02,200 --> 00:02:04,240
System behavior is the only thing that matters.

57
00:02:04,240 --> 00:02:05,320
The system did what it did.

58
00:02:05,320 --> 00:02:06,320
A guest got access.

59
00:02:06,320 --> 00:02:08,080
A link exists, a flow ran.

60
00:02:08,080 --> 00:02:09,560
A team persisted without an owner.

61
00:02:09,560 --> 00:02:11,440
The tenant doesn't care about your intent.

62
00:02:11,440 --> 00:02:14,080
And once you accept that, you start seeing why

63
00:02:14,080 --> 00:02:17,520
we set the policy becomes, we assumed the policy.

64
00:02:17,520 --> 00:02:20,120
Because most governance is really just visibility,

65
00:02:20,120 --> 00:02:23,200
a report, a dashboard, a quarterly review meeting.

66
00:02:23,200 --> 00:02:24,600
That is governance theater.

67
00:02:24,600 --> 00:02:26,760
Visibility without consequence.

68
00:02:26,760 --> 00:02:29,200
You can have perfect reporting and still have zero control

69
00:02:29,200 --> 00:02:31,320
if nothing happens when the report finds a problem.

70
00:02:31,320 --> 00:02:34,080
If the system detects drift and nobody's forced to fix it,

71
00:02:34,080 --> 00:02:35,200
you are not governing.

72
00:02:35,200 --> 00:02:36,960
You are collecting evidence of decay.

73
00:02:36,960 --> 00:02:39,400
This is the part people hate hearing, but it's true.

74
00:02:39,400 --> 00:02:42,320
Native Microsoft 365 governance is mostly a set

75
00:02:42,320 --> 00:02:44,520
of controls scattered across product boundaries.

76
00:02:44,520 --> 00:02:46,880
Admin centers are not a unified governance plane.

77
00:02:46,880 --> 00:02:50,120
They are organizational charts rendered as user interfaces.

78
00:02:50,120 --> 00:02:51,720
So what happens in reality?

79
00:02:51,720 --> 00:02:54,120
Control fails in the gap between the control plane

80
00:02:54,120 --> 00:02:54,960
and the work plane.

81
00:02:54,960 --> 00:02:57,400
The control plane is where you configure settings.

82
00:02:57,400 --> 00:03:01,440
Admin centers, entra policies, DLP policies, labels,

83
00:03:01,440 --> 00:03:03,160
retention, conditional access.

84
00:03:03,160 --> 00:03:05,080
The work plane is where work actually happens.

85
00:03:05,080 --> 00:03:07,320
People create teams from teams, from planner,

86
00:03:07,320 --> 00:03:08,960
from templates, from apps.

87
00:03:08,960 --> 00:03:10,400
They share files from one drive.

88
00:03:10,400 --> 00:03:12,760
They build flows from a team's chat prompt.

89
00:03:12,760 --> 00:03:15,360
They invite guests because the project needs it now.

90
00:03:15,360 --> 00:03:18,120
Governance collapses when the work plane has more creation

91
00:03:18,120 --> 00:03:20,760
pathways than the control plane has enforcement points.

92
00:03:20,760 --> 00:03:22,160
And it always does.

93
00:03:22,160 --> 00:03:24,360
Once you nail that, everything else clicks.

94
00:03:24,360 --> 00:03:26,320
Governance outcomes are deterministic only

95
00:03:26,320 --> 00:03:27,880
when enforcement is deterministic.

96
00:03:27,880 --> 00:03:29,600
If you rely on humans remembering,

97
00:03:29,600 --> 00:03:31,560
governance becomes probabilistic.

98
00:03:31,560 --> 00:03:33,040
We usually do the review.

99
00:03:33,040 --> 00:03:34,880
We try to keep owners updated.

100
00:03:34,880 --> 00:03:36,520
We expect teams to expire.

101
00:03:36,520 --> 00:03:37,520
That's not governance.

102
00:03:37,520 --> 00:03:39,560
That's wishful thinking with an audit trail.

103
00:03:39,560 --> 00:03:42,080
The reason this works as a framing is that entropy

104
00:03:42,080 --> 00:03:44,800
accumulates through small exceptions.

105
00:03:44,800 --> 00:03:48,000
Every just this once becomes an entropy generator.

106
00:03:48,000 --> 00:03:50,560
Every bypass you allow, temporary guest access,

107
00:03:50,560 --> 00:03:53,680
a one off sharing link, a maker allowed to use a connector.

108
00:03:53,680 --> 00:03:58,000
Creates a pathway that will be reused, copied, and forgotten.

109
00:03:58,000 --> 00:04:00,200
Over time, policies drift away from intent

110
00:04:00,200 --> 00:04:03,040
and the tenant becomes a collection of historical accidents.

111
00:04:03,040 --> 00:04:03,920
And here's the trap.

112
00:04:03,920 --> 00:04:06,280
The platform will happily let you live in that state.

113
00:04:06,280 --> 00:04:07,040
It won't scream.

114
00:04:07,040 --> 00:04:07,760
It won't break.

115
00:04:07,760 --> 00:04:09,680
It will just keep producing resources faster

116
00:04:09,680 --> 00:04:10,760
than you can review them.

117
00:04:10,760 --> 00:04:12,840
So if you remember nothing else from this section,

118
00:04:12,840 --> 00:04:14,080
remember this.

119
00:04:14,080 --> 00:04:16,520
Configuration is not control.

120
00:04:16,520 --> 00:04:19,760
Control is enforced, continuous, and cross-service.

121
00:04:19,760 --> 00:04:22,120
If your governance model can't survive turnover,

122
00:04:22,120 --> 00:04:24,400
new workloads, new defaults, and people doing what

123
00:04:24,400 --> 00:04:27,720
the platform makes easy, then you don't have a governance model.

124
00:04:27,720 --> 00:04:28,960
You have a governance moment.

125
00:04:28,960 --> 00:04:30,080
Now, the uncomfortable truth.

126
00:04:30,080 --> 00:04:31,920
If governance has to survive entropy,

127
00:04:31,920 --> 00:04:34,360
it needs primitives that don't decay under scale,

128
00:04:34,360 --> 00:04:36,760
ownership, life cycle, enforcement, and proof.

129
00:04:36,760 --> 00:04:40,480
Not best practices, not admin checklists, primitives.

130
00:04:40,480 --> 00:04:42,080
And that's where we go next.

131
00:04:42,080 --> 00:04:44,360
Microsoft 365 governance fundamentals

132
00:04:44,360 --> 00:04:46,320
that survive contact with reality.

133
00:04:46,320 --> 00:04:48,440
Governance that survives contact with reality

134
00:04:48,440 --> 00:04:51,280
starts with admitting what the system is optimized for,

135
00:04:51,280 --> 00:04:54,720
creating things, sharing things, automating things,

136
00:04:54,720 --> 00:04:57,160
not retiring things, not keeping ownership current,

137
00:04:57,160 --> 00:04:59,000
not keeping permissions aligned with intent.

138
00:04:59,000 --> 00:05:00,800
So the only governance fundamentals that work

139
00:05:00,800 --> 00:05:02,720
are the ones that treat this ecosystem

140
00:05:02,720 --> 00:05:05,240
like a living authorization graph that constantly decays.

141
00:05:05,240 --> 00:05:07,840
There are four primitives that hold up under that pressure.

142
00:05:07,840 --> 00:05:11,240
Ownership, life cycle, enforcement, and transparency.

143
00:05:11,240 --> 00:05:14,040
Everything else is decoration.

144
00:05:14,040 --> 00:05:16,120
First, ownership and accountability.

145
00:05:16,120 --> 00:05:18,560
This is the root primitive because every other control

146
00:05:18,560 --> 00:05:21,240
depends on having someone to root decisions to.

147
00:05:21,240 --> 00:05:23,360
People love to treat ownership as metadata.

148
00:05:23,360 --> 00:05:24,120
It isn't.

149
00:05:24,120 --> 00:05:25,880
Ownership is an operational circuit.

150
00:05:25,880 --> 00:05:28,040
It is the difference between this looks risky

151
00:05:28,040 --> 00:05:29,560
and this gets fixed.

152
00:05:29,560 --> 00:05:34,320
If a team, site, group, flow, app, or agent

153
00:05:34,320 --> 00:05:36,800
has no accountable owner, you have an often

154
00:05:36,800 --> 00:05:38,040
authorization surface.

155
00:05:38,040 --> 00:05:38,800
It will persist.

156
00:05:38,800 --> 00:05:39,400
It will drift.

157
00:05:39,400 --> 00:05:41,400
It will outlive the project that created it.

158
00:05:41,400 --> 00:05:43,160
And in an audit, who approved this

159
00:05:43,160 --> 00:05:45,640
becomes a philosophical question, not a traceable answer.

160
00:05:45,640 --> 00:05:48,680
So ownership governance is not make sure there are two owners.

161
00:05:48,680 --> 00:05:51,080
That's necessary, but it's not sufficient.

162
00:05:51,080 --> 00:05:54,280
Ownership governance is minimum owners, verified owners,

163
00:05:54,280 --> 00:05:56,480
and enforced reassignment when owners disappear.

164
00:05:56,480 --> 00:05:58,760
Because owners leave, contractors roll off,

165
00:05:58,760 --> 00:05:59,840
people change roles.

166
00:05:59,840 --> 00:06:01,160
The system keeps the resource.

167
00:06:01,160 --> 00:06:02,880
That distinction matters.

168
00:06:02,880 --> 00:06:04,440
Second, life cycle management.

169
00:06:04,440 --> 00:06:06,720
Life cycle is the only sprawl countermeasure

170
00:06:06,720 --> 00:06:09,480
that actually scales because it operates on time, not memory.

171
00:06:09,480 --> 00:06:10,600
Humans forget.

172
00:06:10,600 --> 00:06:11,800
Time doesn't.

173
00:06:11,800 --> 00:06:13,960
Life cycle means you treat workspaces

174
00:06:13,960 --> 00:06:16,920
and automation like assets with a start date, a use phase,

175
00:06:16,920 --> 00:06:18,480
and an end-of-life event.

176
00:06:18,480 --> 00:06:21,520
And if you don't define the end, the platform will define it for you.

177
00:06:21,520 --> 00:06:22,640
Never.

178
00:06:22,640 --> 00:06:24,120
Now, here's where most people mess up.

179
00:06:24,120 --> 00:06:26,040
They confuse inactivity with deletion.

180
00:06:26,040 --> 00:06:27,640
Inactivity is just silence.

181
00:06:27,640 --> 00:06:29,400
Silence is not the absence of risk.

182
00:06:29,400 --> 00:06:32,680
An inactive team with an old guest and a lingering anyone

183
00:06:32,680 --> 00:06:36,720
with the link file is a quiet liability, not a solved problem.

184
00:06:36,720 --> 00:06:39,040
Life cycle governance means you have triggers.

185
00:06:39,040 --> 00:06:42,440
Expire renewal, archival, deletion, and escalation

186
00:06:42,440 --> 00:06:43,440
when nobody responds.

187
00:06:43,440 --> 00:06:44,840
It's not an annual clean-up day.

188
00:06:44,840 --> 00:06:47,280
It's a continuous pressure that forces resources

189
00:06:47,280 --> 00:06:49,920
to either prove relevance or die.

190
00:06:49,920 --> 00:06:51,560
Third, policy enforcement.

191
00:06:51,560 --> 00:06:53,880
This is where the fantasy collapses for most organizations

192
00:06:53,880 --> 00:06:57,120
because policy is easy and enforcement is expensive.

193
00:06:57,120 --> 00:06:59,400
Enforcement has only a handful of real verbs.

194
00:06:59,400 --> 00:07:03,160
Block, force, expire, escalate, and remediate.

195
00:07:03,160 --> 00:07:06,240
Block means the action cannot happen without meeting conditions.

196
00:07:06,240 --> 00:07:09,400
Force means the user can proceed only through a controlled path.

197
00:07:09,400 --> 00:07:11,440
Expire means the system removes access

198
00:07:11,440 --> 00:07:13,240
unless someone re-attests.

199
00:07:13,240 --> 00:07:15,600
Escalate means the decision is rooted up a chain

200
00:07:15,600 --> 00:07:17,400
when the accountable person doesn't act.

201
00:07:17,400 --> 00:07:19,800
Remediate means the system can take corrective action

202
00:07:19,800 --> 00:07:22,280
automatically, not just report the issue.

203
00:07:22,280 --> 00:07:24,800
If your governance controls don't use those verbs,

204
00:07:24,800 --> 00:07:25,760
they are not controls.

205
00:07:25,760 --> 00:07:26,960
They are suggestions.

206
00:07:26,960 --> 00:07:28,960
And yes, you can do some of this natively.

207
00:07:28,960 --> 00:07:30,680
Conditional access blocks some access,

208
00:07:30,680 --> 00:07:32,880
DLP blocks some connectors, sharing settings,

209
00:07:32,880 --> 00:07:34,680
constraints, some link types.

210
00:07:34,680 --> 00:07:37,120
Retention can force life cycle on content.

211
00:07:37,120 --> 00:07:38,680
But the native problem is consistency.

212
00:07:38,680 --> 00:07:41,000
Enforcement primitives vary by workload.

213
00:07:41,000 --> 00:07:44,160
The system enforces in one place and merely reports in another.

214
00:07:44,160 --> 00:07:45,520
That creates conditional chaos,

215
00:07:45,520 --> 00:07:48,560
a deterministic intent implemented as probabilistic behavior.

216
00:07:48,560 --> 00:07:49,920
Fourth, transparency.

217
00:07:49,920 --> 00:07:51,840
Not in the dashboard for leadership sense

218
00:07:51,840 --> 00:07:53,400
in the explainable decision sense.

219
00:07:53,400 --> 00:07:55,800
A government tenant must be able to answer three questions

220
00:07:55,800 --> 00:07:56,680
on demand.

221
00:07:56,680 --> 00:07:57,520
What exists?

222
00:07:57,520 --> 00:07:58,280
Who owns it?

223
00:07:58,280 --> 00:07:59,720
And why access is allowed?

224
00:07:59,720 --> 00:08:00,480
Not eventually.

225
00:08:00,480 --> 00:08:02,560
Not after a week of exporting CSVs

226
00:08:02,560 --> 00:08:04,960
and reconciling admin centers on demand.

227
00:08:04,960 --> 00:08:06,280
That's auditability.

228
00:08:06,280 --> 00:08:07,880
And it's also operational sanity.

229
00:08:07,880 --> 00:08:09,720
Now, a common response here is fine.

230
00:08:09,720 --> 00:08:10,720
We'll do reviews.

231
00:08:10,720 --> 00:08:12,600
This clicked for a lot of people the hard way.

232
00:08:12,600 --> 00:08:14,160
Manual reviews don't scale.

233
00:08:14,160 --> 00:08:15,640
Not because the reviewers are lazy,

234
00:08:15,640 --> 00:08:17,320
but because volume and drift compound,

235
00:08:17,320 --> 00:08:18,960
a human review process is a queue.

236
00:08:18,960 --> 00:08:21,160
Microsoft 365 is a fire hose.

237
00:08:21,160 --> 00:08:24,160
As volume grows, reviewer fatigue becomes an entropy generator.

238
00:08:24,160 --> 00:08:25,240
People rubber stamp.

239
00:08:25,240 --> 00:08:27,200
They approve because rejecting creates work.

240
00:08:27,200 --> 00:08:30,160
They accept risk because the system made the risky thing easy

241
00:08:30,160 --> 00:08:31,520
and the safe thing slow.

242
00:08:31,520 --> 00:08:34,240
So the governance fundamental is not do more reviews.

243
00:08:34,240 --> 00:08:36,440
It's design reviews that create consequences.

244
00:08:36,440 --> 00:08:37,640
Reviews must be time bound,

245
00:08:37,640 --> 00:08:39,680
tied to ownership and backed by enforcement.

246
00:08:39,680 --> 00:08:42,240
If you don't review, the system expires or escalates.

247
00:08:42,240 --> 00:08:44,280
Otherwise, the review is theater.

248
00:08:44,280 --> 00:08:46,000
And that brings us to the failure pattern

249
00:08:46,000 --> 00:08:47,720
behind most governance programs.

250
00:08:47,720 --> 00:08:49,160
They are treated like projects.

251
00:08:49,160 --> 00:08:51,000
They ship a policy set, declare victory,

252
00:08:51,000 --> 00:08:52,640
and then drift begins the next morning.

253
00:08:52,640 --> 00:08:54,920
So if governance has to survive reality,

254
00:08:54,920 --> 00:08:57,760
you anchor it on primitives that don't rely on hope,

255
00:08:57,760 --> 00:09:01,280
ownership, life cycle, enforcement and transparency.

256
00:09:01,280 --> 00:09:03,640
Now, we can talk about why your last governance rollout

257
00:09:03,640 --> 00:09:05,000
didn't fail during deployment.

258
00:09:05,000 --> 00:09:06,760
It failed afterwards.

259
00:09:06,760 --> 00:09:09,000
When drift became the default state,

260
00:09:09,000 --> 00:09:12,120
the failure loop projects end drift begins.

261
00:09:12,120 --> 00:09:14,600
Governance programs don't usually fail during rollout.

262
00:09:14,600 --> 00:09:16,120
They fail after the rollout

263
00:09:16,120 --> 00:09:18,240
because most organizations treat governance

264
00:09:18,240 --> 00:09:20,920
like a migration task, design the policies,

265
00:09:20,920 --> 00:09:22,760
deploy the tooling, publish the guidance,

266
00:09:22,760 --> 00:09:24,680
run the training, declare success.

267
00:09:24,680 --> 00:09:26,120
Then everyone goes back to real work

268
00:09:26,120 --> 00:09:27,680
and assumes the controls will hold.

269
00:09:27,680 --> 00:09:28,520
They won't.

270
00:09:28,520 --> 00:09:29,600
The system does not preserve intent.

271
00:09:29,600 --> 00:09:31,160
It preserves state.

272
00:09:31,160 --> 00:09:34,040
And state decays the moment people start using the platform

273
00:09:34,040 --> 00:09:35,760
in ways the platform makes convenient.

274
00:09:35,760 --> 00:09:38,280
So the failure loop looks the same almost everywhere.

275
00:09:38,280 --> 00:09:40,480
First, there's a one time rollout mindset.

276
00:09:40,480 --> 00:09:42,840
We implemented sensitivity labels.

277
00:09:42,840 --> 00:09:44,680
We configured external sharing.

278
00:09:44,680 --> 00:09:45,880
We set up DLP.

279
00:09:45,880 --> 00:09:47,000
We blocked group creation.

280
00:09:47,000 --> 00:09:49,000
Here, in project terms, those are deliverables.

281
00:09:49,000 --> 00:09:51,160
In governance terms, they are starting conditions.

282
00:09:51,160 --> 00:09:53,120
The problem is not that those controls are useless.

283
00:09:53,120 --> 00:09:55,920
The problem is that they don't stay aligned with reality

284
00:09:55,920 --> 00:09:58,880
without a mechanism that forces them to be revalidated.

285
00:09:58,880 --> 00:10:00,400
A tenant is not a network appliance.

286
00:10:00,400 --> 00:10:02,160
It's a constant stream of new objects,

287
00:10:02,160 --> 00:10:04,160
new links, new connections, new identities

288
00:10:04,160 --> 00:10:05,000
and new exceptions.

289
00:10:05,000 --> 00:10:06,480
So drift begins in three places.

290
00:10:06,480 --> 00:10:08,680
Exceptions, bypasses and new surfaces.

291
00:10:08,680 --> 00:10:10,000
Exceptions are the obvious one.

292
00:10:10,000 --> 00:10:12,160
Something breaks, the business escalates

293
00:10:12,160 --> 00:10:13,480
and you add an allow clause.

294
00:10:13,480 --> 00:10:14,920
Then another one, then another one.

295
00:10:14,920 --> 00:10:17,320
Each exception is a permanent policy fork.

296
00:10:17,320 --> 00:10:19,520
The platform doesn't remember that the exception

297
00:10:19,520 --> 00:10:20,920
was supposed to be temporary.

298
00:10:20,920 --> 00:10:22,480
It just remembers that it's allowed.

299
00:10:22,480 --> 00:10:25,160
Bipasses are worse because they're often invisible.

300
00:10:25,160 --> 00:10:27,720
The team's admin thinks team creation is constrained,

301
00:10:27,720 --> 00:10:30,360
but someone creates a Microsoft 365 group

302
00:10:30,360 --> 00:10:32,480
from Outlook or Planner or an app.

303
00:10:32,480 --> 00:10:35,640
The SharePoint admin thinks external sharing is controlled.

304
00:10:35,640 --> 00:10:37,440
But someone shares a file from one drive

305
00:10:37,440 --> 00:10:39,360
with a link type that wasn't considered.

306
00:10:39,360 --> 00:10:42,360
The power platform admin thinks environments are governed

307
00:10:42,360 --> 00:10:44,880
but makers are still building in the default environment

308
00:10:44,880 --> 00:10:46,320
because it's there and it works.

309
00:10:46,320 --> 00:10:47,800
And then you get new surfaces.

310
00:10:47,800 --> 00:10:50,080
Microsoft ships new functionality constantly.

311
00:10:50,080 --> 00:10:52,200
New channel types, new sharing experiences,

312
00:10:52,200 --> 00:10:55,240
new co-pilot features, new connectors, new defaults,

313
00:10:55,240 --> 00:10:57,360
every new surface is a new pathway.

314
00:10:57,360 --> 00:10:59,040
And it arrives with default behavior

315
00:10:59,040 --> 00:11:01,240
that reflects a product team's incentives,

316
00:11:01,240 --> 00:11:02,480
not your audit requirements.

317
00:11:02,480 --> 00:11:04,920
Now here's the part that actually kills governance programs.

318
00:11:04,920 --> 00:11:05,960
Review a fatigue.

319
00:11:05,960 --> 00:11:08,760
Organizations respond to drift by adding more reviews,

320
00:11:08,760 --> 00:11:11,880
quarterly access reviews, annual site audits,

321
00:11:11,880 --> 00:11:13,800
monthly owner attestations.

322
00:11:13,800 --> 00:11:17,320
It looks responsible, but a review process is a human queue.

323
00:11:17,320 --> 00:11:19,440
And your tenant is a machine that produces work

324
00:11:19,440 --> 00:11:21,280
faster than humans can validate it.

325
00:11:21,280 --> 00:11:22,960
So the review becomes a ritual.

326
00:11:22,960 --> 00:11:24,240
People rubber stamp.

327
00:11:24,240 --> 00:11:26,640
They approve because they don't want to break collaboration.

328
00:11:26,640 --> 00:11:29,280
They approve because they don't know what the resource is anymore.

329
00:11:29,280 --> 00:11:30,760
They approve because the owner left

330
00:11:30,760 --> 00:11:31,920
and they inherited the mess.

331
00:11:31,920 --> 00:11:33,080
That's not malicious.

332
00:11:33,080 --> 00:11:34,040
That's predictable.

333
00:11:35,000 --> 00:11:37,040
Rubber stamping is an entropy generator.

334
00:11:37,040 --> 00:11:39,400
It converts uncertainty into permanent approval.

335
00:11:39,400 --> 00:11:41,640
It turns, we don't know, into, we accept.

336
00:11:41,640 --> 00:11:43,320
And after a year or two, the organization

337
00:11:43,320 --> 00:11:45,240
can't distinguish between deliberate access

338
00:11:45,240 --> 00:11:46,400
and historical accident.

339
00:11:46,400 --> 00:11:48,280
Then comes the default settings myth.

340
00:11:48,280 --> 00:11:50,640
At tenant scale, safety faults do not exist,

341
00:11:50,640 --> 00:11:52,160
not because Microsoft is negligent,

342
00:11:52,160 --> 00:11:54,520
because defaults have to work for millions of customers

343
00:11:54,520 --> 00:11:56,360
with contradictory requirements.

344
00:11:56,360 --> 00:11:58,080
Defaults optimize adoption.

345
00:11:58,080 --> 00:11:59,360
You optimize control.

346
00:11:59,360 --> 00:12:00,600
Those goals are not aligned.

347
00:12:00,600 --> 00:12:03,360
So when an admin says, we left it at default.

348
00:12:03,360 --> 00:12:05,880
What they mean is, we delegated the security model

349
00:12:05,880 --> 00:12:07,720
to the product team and hope the business

350
00:12:07,720 --> 00:12:09,440
wouldn't discover the sharp edges.

351
00:12:09,440 --> 00:12:09,960
They will.

352
00:12:09,960 --> 00:12:11,480
And finally, measurement fails.

353
00:12:11,480 --> 00:12:14,200
This is subtle because most organizations do have reporting.

354
00:12:14,200 --> 00:12:16,120
They can show counts, number of teams, number of guests,

355
00:12:16,120 --> 00:12:18,600
number of sharing links, number of DLP hits, number of flows.

356
00:12:18,600 --> 00:12:19,960
They can even show trends.

357
00:12:19,960 --> 00:12:21,920
But reporting that doesn't change outcomes

358
00:12:21,920 --> 00:12:23,600
is just a different kind of theater.

359
00:12:23,600 --> 00:12:26,440
If a dashboard says you have 10,000 externally shared files

360
00:12:26,440 --> 00:12:29,200
and nothing happens, the dashboard is not governance.

361
00:12:29,200 --> 00:12:31,240
It's a weekly reminder that you're operating

362
00:12:31,240 --> 00:12:33,160
a probabilistic security model.

363
00:12:33,160 --> 00:12:36,280
Governance only exists where reporting triggers consequence.

364
00:12:36,280 --> 00:12:39,120
Detect, root, remediate, prove.

365
00:12:39,120 --> 00:12:41,800
Without that loop, the failure pattern is deterministic.

366
00:12:41,800 --> 00:12:43,280
Projects end.

367
00:12:43,280 --> 00:12:45,000
Drift begins.

368
00:12:45,000 --> 00:12:46,400
The tenant decays.

369
00:12:46,400 --> 00:12:48,240
Then you launch another governance project

370
00:12:48,240 --> 00:12:51,000
to fix the sprawl created by the last one.

371
00:12:51,000 --> 00:12:53,160
That is how governance becomes a permanent series

372
00:12:53,160 --> 00:12:55,640
of cleanup campaigns instead of a control system.

373
00:12:55,640 --> 00:12:58,400
And once you see the loop, you also see what comes next.

374
00:12:58,400 --> 00:13:00,120
The erosion patterns are not random.

375
00:13:00,120 --> 00:13:00,880
They're repeatable.

376
00:13:00,880 --> 00:13:02,240
They compound.

377
00:13:02,240 --> 00:13:04,000
And they appear in every tenant because they

378
00:13:04,000 --> 00:13:07,560
are structural outcomes of how Microsoft 365 works at scale.

379
00:13:07,560 --> 00:13:09,640
So next, we map the five erosion patterns,

380
00:13:09,640 --> 00:13:11,480
the predictable ways a tenant decays.

381
00:13:11,480 --> 00:13:13,440
So you can stop being surprised by them.

382
00:13:13,440 --> 00:13:16,520
The five erosion patterns, a map of how tenants decay.

383
00:13:16,520 --> 00:13:17,960
Here's the part that should bother you.

384
00:13:17,960 --> 00:13:19,360
Tennis don't decay randomly.

385
00:13:19,360 --> 00:13:22,200
They decay in the same directions for the same reasons

386
00:13:22,200 --> 00:13:24,880
in almost every organization that has real adoption.

387
00:13:24,880 --> 00:13:26,280
Not because admins are careless.

388
00:13:26,280 --> 00:13:29,560
Because Microsoft 365 is a system that continuously produces

389
00:13:29,560 --> 00:13:32,000
resources, permissions, and automation pathways

390
00:13:32,000 --> 00:13:34,120
faster than any human process can validate.

391
00:13:34,120 --> 00:13:35,440
So what follows is a map.

392
00:13:35,440 --> 00:13:37,440
Five erosion patterns that show up again and again.

393
00:13:37,440 --> 00:13:39,400
If you can name the pattern, you can predict it.

394
00:13:39,400 --> 00:13:41,360
If you can predict it, you can design controls

395
00:13:41,360 --> 00:13:43,400
that don't rely on optimism.

396
00:13:43,400 --> 00:13:45,880
Pattern one is sprawl.

397
00:13:45,880 --> 00:13:47,640
sprawl is not too many teams.

398
00:13:47,640 --> 00:13:49,520
sprawl is uncontrolled creation combined

399
00:13:49,520 --> 00:13:50,920
with weak life cycle.

400
00:13:50,920 --> 00:13:54,280
Its teams, groups, sites, channels, plans, chats, meeting

401
00:13:54,280 --> 00:13:56,440
artifacts, shared files, and now agents

402
00:13:56,440 --> 00:13:59,920
multiplying through every convenience pathway the platform offers.

403
00:13:59,920 --> 00:14:02,320
Even if you restrict creation in one place,

404
00:14:02,320 --> 00:14:04,680
creation reappears somewhere else.

405
00:14:04,680 --> 00:14:07,520
sprawl is the system expressing its default behavior.

406
00:14:07,520 --> 00:14:09,960
Decentralize creation, centralize cleanup,

407
00:14:09,960 --> 00:14:11,280
and call that governance.

408
00:14:11,280 --> 00:14:13,000
Pattern two is sharing drift.

409
00:14:13,000 --> 00:14:15,240
Sharing drift is what happens when a workspace

410
00:14:15,240 --> 00:14:17,040
begins in a known state.

411
00:14:17,040 --> 00:14:20,200
Private team, controlled site, sensible membership,

412
00:14:20,200 --> 00:14:22,160
and then slowly accumulates exceptions

413
00:14:22,160 --> 00:14:24,080
at the file and folder level.

414
00:14:24,080 --> 00:14:26,240
Sharing links expire inconsistently.

415
00:14:26,240 --> 00:14:28,680
Inheritance breaks invisibly, and just

416
00:14:28,680 --> 00:14:30,800
share it quickly becomes permanent exposure.

417
00:14:30,800 --> 00:14:32,760
The thing most people miss is that sharing drift

418
00:14:32,760 --> 00:14:34,600
doesn't require malicious intent.

419
00:14:34,600 --> 00:14:35,880
It only requires time.

420
00:14:35,880 --> 00:14:38,080
Every collaboration moment deposits a little access

421
00:14:38,080 --> 00:14:39,280
that nobody pays it back.

422
00:14:39,280 --> 00:14:41,560
Pattern three is data-exfiltration pathways.

423
00:14:41,560 --> 00:14:43,560
This is not just external sharing this up.

424
00:14:43,560 --> 00:14:46,320
This is any mechanism that moves data from a governed domain

425
00:14:46,320 --> 00:14:47,400
to an ungoverned domain.

426
00:14:47,400 --> 00:14:50,120
Email downloads, sync clients, unmanaged devices,

427
00:14:50,120 --> 00:14:54,160
third-party SaaS, and at enterprise scale automation.

428
00:14:54,160 --> 00:14:57,240
The platform is full of legitimate export mechanisms,

429
00:14:57,240 --> 00:14:59,280
and governance fails when you can't distinguish

430
00:14:59,280 --> 00:15:01,880
an intentional data flow from an accidental one.

431
00:15:01,880 --> 00:15:03,360
The exfiltration pattern is structural

432
00:15:03,360 --> 00:15:05,280
because Microsoft 365 is designed

433
00:15:05,280 --> 00:15:07,440
to connect, integrate, and automate.

434
00:15:07,440 --> 00:15:09,920
The control problem isn't stop data leaving.

435
00:15:09,920 --> 00:15:11,800
It's stop data leaving without intent,

436
00:15:11,800 --> 00:15:13,680
approval, and traceable accountability.

437
00:15:13,680 --> 00:15:15,360
Pattern four is AI exposure.

438
00:15:15,360 --> 00:15:17,760
AI exposure is not a new risk category.

439
00:15:17,760 --> 00:15:20,600
It is an acceleration layer on top of the first three patterns.

440
00:15:20,600 --> 00:15:22,680
Co-pilot collapses the cost of discovery.

441
00:15:22,680 --> 00:15:24,840
What used to be hard, finding a forgotten file

442
00:15:24,840 --> 00:15:27,280
in a forgotten site with overly broad permissions,

443
00:15:27,280 --> 00:15:28,800
becomes one prompt away.

444
00:15:28,800 --> 00:15:30,280
That is not co-pilot being dangerous.

445
00:15:30,280 --> 00:15:33,120
That is co-pilot making your existing authorization model

446
00:15:33,120 --> 00:15:34,280
visible at human speed.

447
00:15:34,280 --> 00:15:35,800
It turns drift into output.

448
00:15:35,800 --> 00:15:38,200
And because it's fast, it exposes how little of your data

449
00:15:38,200 --> 00:15:40,200
state is actually curated for relevance,

450
00:15:40,200 --> 00:15:41,840
not just protected for compliance.

451
00:15:41,840 --> 00:15:43,680
Pattern five is onalous resources.

452
00:15:43,680 --> 00:15:46,400
This is the silent killer because it doesn't trigger alarms.

453
00:15:46,400 --> 00:15:48,120
Onalous teams still work.

454
00:15:48,120 --> 00:15:49,920
Onalous sites still serve files.

455
00:15:49,920 --> 00:15:51,240
Onalous flows still run.

456
00:15:51,240 --> 00:15:52,920
Onalous apps still collect data.

457
00:15:52,920 --> 00:15:54,960
They persist through layoffs, reorganizations,

458
00:15:54,960 --> 00:15:56,640
M&A, and simple boredom.

459
00:15:56,640 --> 00:15:59,160
And onalous resources are the point where governance

460
00:15:59,160 --> 00:16:01,080
becomes mathematically impossible.

461
00:16:01,080 --> 00:16:03,840
Because every remediation path needs a responsible human.

462
00:16:03,840 --> 00:16:05,600
If there is no owner, you can't attest.

463
00:16:05,600 --> 00:16:06,480
You can't approve.

464
00:16:06,480 --> 00:16:08,000
You can't expire with confidence.

465
00:16:08,000 --> 00:16:10,040
You can't even ask a meaningful question

466
00:16:10,040 --> 00:16:11,400
because nobody has context.

467
00:16:11,400 --> 00:16:12,400
Now, why these five?

468
00:16:12,400 --> 00:16:14,880
Because they're structural, not admin mistakes.

469
00:16:14,880 --> 00:16:17,200
Sproul happens because creation is decentralized

470
00:16:17,200 --> 00:16:20,280
and frictionless while retirement is centralized and slow.

471
00:16:20,280 --> 00:16:22,640
Sharing drift happens because collaboration happens

472
00:16:22,640 --> 00:16:25,560
at file level while oversight happens at site level.

473
00:16:25,560 --> 00:16:27,600
Exfiltration happens because integration

474
00:16:27,600 --> 00:16:29,760
is the value proposition and you cannot ban

475
00:16:29,760 --> 00:16:31,640
your way out of your own business processes.

476
00:16:31,640 --> 00:16:34,320
AI exposure happens because AI is a discovery

477
00:16:34,320 --> 00:16:36,840
and synthesis layer that consumes whatever permissions

478
00:16:36,840 --> 00:16:37,800
already allow.

479
00:16:37,800 --> 00:16:40,200
Onalous resources happen because identity life cycle

480
00:16:40,200 --> 00:16:42,320
is managed but resource life cycle is not.

481
00:16:42,320 --> 00:16:45,160
And the compounding effect is where the real risk leaves.

482
00:16:45,160 --> 00:16:46,800
These patterns amplify each other.

483
00:16:46,800 --> 00:16:50,240
Sproul creates more places for sharing drift to accumulate.

484
00:16:50,240 --> 00:16:52,280
Sharing drift increases the blast radius

485
00:16:52,280 --> 00:16:53,480
for co-pilot discovery.

486
00:16:53,480 --> 00:16:56,520
Automation turns sharing drift into automated exfiltration.

487
00:16:56,520 --> 00:16:59,320
Ownerless resources ensure none of it gets cleaned up.

488
00:16:59,320 --> 00:17:01,000
Now we hit the native tooling limit.

489
00:17:01,000 --> 00:17:03,560
Not because Microsoft doesn't provide controls, it does.

490
00:17:03,560 --> 00:17:04,440
Plenty.

491
00:17:04,440 --> 00:17:06,440
But the controls live in workload silos

492
00:17:06,440 --> 00:17:09,640
with partial telemetry, inconsistent enforcement primitives

493
00:17:09,640 --> 00:17:11,920
and different definitions of owner, member, guest,

494
00:17:11,920 --> 00:17:14,840
and external access depending on where you're standing.

495
00:17:14,840 --> 00:17:17,440
So governance becomes manual correlation work,

496
00:17:17,440 --> 00:17:20,080
exporting lists, reconciling, mismatched

497
00:17:20,080 --> 00:17:23,960
identifiers, and arguing about what compliant means this month.

498
00:17:23,960 --> 00:17:25,520
Predictable control looks different.

499
00:17:25,520 --> 00:17:27,840
Predictable control means you can inventory everything

500
00:17:27,840 --> 00:17:30,000
cross-service, attach ownership everywhere

501
00:17:30,000 --> 00:17:33,280
and force life cycle by default and prioritize remediation

502
00:17:33,280 --> 00:17:34,800
by risk instead of noise.

503
00:17:34,800 --> 00:17:37,480
Not perfect control, predictable control.

504
00:17:37,480 --> 00:17:40,000
And to make this concrete, we start with the most visible

505
00:17:40,000 --> 00:17:42,840
rot because it's the easiest place to stop pretending.

506
00:17:42,840 --> 00:17:43,800
Teams sprawl.

507
00:17:43,800 --> 00:17:47,280
In motion case one, Teams sprawl is not a people problem.

508
00:17:47,280 --> 00:17:49,080
Teams sprawl is the most visible form

509
00:17:49,080 --> 00:17:51,480
of governance failure because everyone can see it.

510
00:17:51,480 --> 00:17:54,080
Duplicate Teams, random naming, half dead channels,

511
00:17:54,080 --> 00:17:56,840
guests sprinkled across workspaces, nobody remembers,

512
00:17:56,840 --> 00:17:59,400
a search experience that feels like archaeology.

513
00:17:59,400 --> 00:18:02,080
And the standard explanation is always the same.

514
00:18:02,080 --> 00:18:04,200
Users are creating too many Teams.

515
00:18:04,200 --> 00:18:05,240
That's comforting.

516
00:18:05,240 --> 00:18:06,480
It's also wrong.

517
00:18:06,480 --> 00:18:08,160
Teams sprawl is not a people problem.

518
00:18:08,160 --> 00:18:09,360
It's an architecture problem.

519
00:18:09,360 --> 00:18:11,640
The system makes creation cheap, reversible,

520
00:18:11,640 --> 00:18:12,760
and socially rewarded.

521
00:18:12,760 --> 00:18:15,240
It makes retirement awkward, political, and optional.

522
00:18:15,240 --> 00:18:17,120
So the system gets what it incentivizes.

523
00:18:17,120 --> 00:18:19,440
The thing most people miss is that Teams sprawl

524
00:18:19,440 --> 00:18:21,040
isn't even just Teams.

525
00:18:21,040 --> 00:18:23,000
Teams is the front door to a bundle,

526
00:18:23,000 --> 00:18:26,520
a Microsoft 365 group, a SharePoint site, a mailbox,

527
00:18:26,520 --> 00:18:30,080
a plan a plan, a one note, meeting artifacts, apps,

528
00:18:30,080 --> 00:18:33,080
and now agents and co-pilots landing in the same space.

529
00:18:33,080 --> 00:18:36,080
When someone creates just a team, they're creating an asset graph.

530
00:18:36,080 --> 00:18:38,920
And that graph will outlive the person who clicked the button.

531
00:18:38,920 --> 00:18:41,040
Now here's where the decay actually starts.

532
00:18:41,040 --> 00:18:42,800
Creation pathways multiply.

533
00:18:42,800 --> 00:18:44,520
A user can create a team from Teams,

534
00:18:44,520 --> 00:18:46,280
but they can also create a group from Outlook.

535
00:18:46,280 --> 00:18:48,680
They can create a plan in planar that lights up a group.

536
00:18:48,680 --> 00:18:50,440
They can create a community and app,

537
00:18:50,440 --> 00:18:52,200
a template-driven workspace,

538
00:18:52,200 --> 00:18:55,280
or an integration that silently provisions the same primitives.

539
00:18:55,280 --> 00:18:56,960
So you lock down creation in one place

540
00:18:56,960 --> 00:18:58,880
and the tenant simply routes around it.

541
00:18:58,880 --> 00:19:01,160
It's not a bypass because users are clever.

542
00:19:01,160 --> 00:19:03,600
It's a bypass because Microsoft 365 is built

543
00:19:03,600 --> 00:19:06,200
from shared primitives exposed through multiple products.

544
00:19:06,200 --> 00:19:07,840
The platform wants you to create.

545
00:19:07,840 --> 00:19:09,040
It offers more doors.

546
00:19:09,040 --> 00:19:11,440
And when you add templates, you add gasoline.

547
00:19:11,440 --> 00:19:12,880
Templates are operationally useful,

548
00:19:12,880 --> 00:19:14,360
but they accelerate duplication

549
00:19:14,360 --> 00:19:16,440
because they make spin-up a workspace,

550
00:19:16,440 --> 00:19:18,480
the default response to uncertainty.

551
00:19:18,480 --> 00:19:20,880
Don't know where this conversation belongs, create a team.

552
00:19:20,880 --> 00:19:23,200
Don't know who needs to collaborate, create a team.

553
00:19:23,200 --> 00:19:24,760
Don't want to touch the existing team

554
00:19:24,760 --> 00:19:26,720
because it's messy, create a team.

555
00:19:26,720 --> 00:19:29,080
Duplicate teams are not a failure of user training.

556
00:19:29,080 --> 00:19:31,720
They are the predictable output of decentralized creation

557
00:19:31,720 --> 00:19:33,120
with no enforced life cycle

558
00:19:33,120 --> 00:19:34,520
and no authoritative directory

559
00:19:34,520 --> 00:19:36,560
of the one true workspace for this thing.

560
00:19:36,560 --> 00:19:38,280
Then you get abandoned workspaces.

561
00:19:38,280 --> 00:19:40,000
This is where governance theater shows up

562
00:19:40,000 --> 00:19:41,440
in its purest form.

563
00:19:41,440 --> 00:19:44,240
Organizations assume inactivity equals irrelevance.

564
00:19:44,240 --> 00:19:45,080
It doesn't.

565
00:19:45,080 --> 00:19:46,680
Inactivity means nobody posted.

566
00:19:46,680 --> 00:19:48,280
It does not mean nobody can access.

567
00:19:48,280 --> 00:19:50,120
It does not mean external access expired.

568
00:19:50,120 --> 00:19:51,960
It does not mean ownership is current

569
00:19:51,960 --> 00:19:54,680
and it absolutely does not mean the share point side

570
00:19:54,680 --> 00:19:57,000
behind it stopped being an exposure surface.

571
00:19:57,000 --> 00:19:59,600
Teams also hides the difference between not used

572
00:19:59,600 --> 00:20:01,600
and not risky and the UI gets quiet.

573
00:20:01,600 --> 00:20:02,640
The risk doesn't.

574
00:20:02,640 --> 00:20:04,240
Now add guests.

575
00:20:04,240 --> 00:20:06,000
Guest access is not inherently bad.

576
00:20:06,000 --> 00:20:07,480
Most organizations need it.

577
00:20:07,480 --> 00:20:10,080
The problem is that guest access is almost always treated

578
00:20:10,080 --> 00:20:11,920
as an event, not a life cycle.

579
00:20:11,920 --> 00:20:13,520
A guest gets invited for a project.

580
00:20:13,520 --> 00:20:15,560
The project ends the guest stays.

581
00:20:15,560 --> 00:20:16,800
Then the owner leaves.

582
00:20:16,800 --> 00:20:18,360
Then nobody remembers the approval.

583
00:20:18,360 --> 00:20:20,840
Time plus turnover equals permanent exposure.

584
00:20:20,840 --> 00:20:23,720
And teams makes this easy because collaboration is the feature.

585
00:20:23,720 --> 00:20:25,440
The platform doesn't want to slow it down.

586
00:20:25,440 --> 00:20:28,520
So unless you force expiration and reattestation,

587
00:20:28,520 --> 00:20:31,040
guest access becomes a long lived exception factory.

588
00:20:31,040 --> 00:20:32,880
Now the next trap is naming policies.

589
00:20:32,880 --> 00:20:35,200
Admin's love naming policies because they are visible.

590
00:20:35,200 --> 00:20:36,240
They feel like order.

591
00:20:36,240 --> 00:20:38,440
They produce a short term dopamine hit.

592
00:20:38,440 --> 00:20:40,160
Look, everything has a prefix now.

593
00:20:40,160 --> 00:20:42,080
But naming is cosmetic order, not governance.

594
00:20:42,080 --> 00:20:44,840
A consistent name doesn't tell you whether the team has an owner.

595
00:20:44,840 --> 00:20:47,240
It doesn't tell you whether a guest still needs access.

596
00:20:47,240 --> 00:20:49,120
It doesn't tell you whether the SharePoint site

597
00:20:49,120 --> 00:20:52,240
behind it has broken inheritance and five anyone links.

598
00:20:52,240 --> 00:20:53,160
It tells you the name.

599
00:20:53,160 --> 00:20:54,440
That's it.

600
00:20:54,440 --> 00:20:56,600
And because naming is easy to enforce,

601
00:20:56,600 --> 00:20:59,000
it often becomes a substitute for the harder work.

602
00:20:59,000 --> 00:21:01,400
Ownership enforcement, life cycle enforcement,

603
00:21:01,400 --> 00:21:03,320
and external access governance.

604
00:21:03,320 --> 00:21:04,760
This is the uncomfortable truth.

605
00:21:04,760 --> 00:21:07,160
Teams sprawl continues even in mature tenants

606
00:21:07,160 --> 00:21:09,120
because teams isn't governed at the team's layer.

607
00:21:09,120 --> 00:21:11,960
It's governed at the Microsoft 365 primitive layer.

608
00:21:11,960 --> 00:21:14,600
And most organizations don't build control at that layer.

609
00:21:14,600 --> 00:21:15,920
They build settings in silos

610
00:21:15,920 --> 00:21:17,560
and hope the work plane behaves.

611
00:21:17,560 --> 00:21:19,440
It won't.

612
00:21:19,440 --> 00:21:21,720
So what does predictable control look like here?

613
00:21:21,720 --> 00:21:23,920
Not stop users from creating teams at it.

614
00:21:23,920 --> 00:21:25,920
That just drives shadow creation elsewhere.

615
00:21:25,920 --> 00:21:28,960
Predictible control means constrained creation pathways

616
00:21:28,960 --> 00:21:32,440
to an intentional process require ownership at creation,

617
00:21:32,440 --> 00:21:34,160
attach life cycle by default,

618
00:21:34,160 --> 00:21:36,400
and treat external collaboration as time bound

619
00:21:36,400 --> 00:21:38,160
reviewable access.

620
00:21:38,160 --> 00:21:40,720
And if you can't enforce those conditions continuously,

621
00:21:40,720 --> 00:21:42,400
the team sprawl is not an anomaly.

622
00:21:42,400 --> 00:21:43,640
It is the default output.

623
00:21:43,640 --> 00:21:45,080
Now follow the dependency chain

624
00:21:45,080 --> 00:21:47,000
because this is where the story gets worse.

625
00:21:47,000 --> 00:21:49,240
Teams sprawl doesn't stay in teams.

626
00:21:49,240 --> 00:21:51,960
It becomes SharePoints sprawl automatically.

627
00:21:51,960 --> 00:21:54,240
Teams governance reality, channels, guests,

628
00:21:54,240 --> 00:21:55,600
and conditional chaos.

629
00:21:55,600 --> 00:21:57,760
Teams governance gets sold as a team's problem.

630
00:21:57,760 --> 00:21:58,600
It isn't.

631
00:21:58,600 --> 00:21:59,760
It's a permission topology problem

632
00:21:59,760 --> 00:22:02,160
that happens to have a chat client glued to the front.

633
00:22:02,160 --> 00:22:04,360
And the permission topology has evolved faster

634
00:22:04,360 --> 00:22:05,960
than most governance models.

635
00:22:05,960 --> 00:22:07,880
That's why so many tenants feel fine

636
00:22:07,880 --> 00:22:09,560
until they don't start with channels

637
00:22:09,560 --> 00:22:11,600
because channels are where the clean story dies.

638
00:22:11,600 --> 00:22:14,200
Standard channels inherit membership from the team.

639
00:22:14,200 --> 00:22:15,600
That's the simple mental model

640
00:22:15,600 --> 00:22:17,520
most organizations still operate on.

641
00:22:17,520 --> 00:22:19,160
But private channels and shared channels

642
00:22:19,160 --> 00:22:20,760
break that model by design.

643
00:22:20,760 --> 00:22:22,040
They introduce sub boundaries

644
00:22:22,040 --> 00:22:24,920
that don't map neatly to your original assumptions

645
00:22:24,920 --> 00:22:27,160
about team membership equals access.

646
00:22:27,160 --> 00:22:28,960
A private channel has its own membership.

647
00:22:28,960 --> 00:22:30,800
It is effectively a separate security island

648
00:22:30,800 --> 00:22:31,960
inside the team.

649
00:22:31,960 --> 00:22:34,120
It solves a real collaboration need,

650
00:22:34,120 --> 00:22:36,000
but it also creates a permission topology.

651
00:22:36,000 --> 00:22:38,320
Most orgs never model, never inventory correctly,

652
00:22:38,320 --> 00:22:40,440
and almost never lifecycle manage.

653
00:22:40,440 --> 00:22:41,880
A shared channel goes further.

654
00:22:41,880 --> 00:22:43,880
It creates cross team collaboration

655
00:22:43,880 --> 00:22:45,880
with a link like behavior.

656
00:22:45,880 --> 00:22:48,120
People from outside the team can participate

657
00:22:48,120 --> 00:22:49,760
without becoming full members of the team.

658
00:22:49,760 --> 00:22:50,720
That sounds controlled,

659
00:22:50,720 --> 00:22:53,400
but it's also a new pathway for access drift

660
00:22:53,400 --> 00:22:55,680
because you've created a collaboration surface

661
00:22:55,680 --> 00:22:58,400
that sits outside the original team membership boundary.

662
00:22:58,400 --> 00:23:00,360
That distinction matters.

663
00:23:00,360 --> 00:23:04,160
Because when you ask, who has access to this workspace,

664
00:23:04,160 --> 00:23:06,080
the correct answer becomes it depends what you mean

665
00:23:06,080 --> 00:23:07,080
by workspace.

666
00:23:07,080 --> 00:23:08,360
Whether the team decide the channel,

667
00:23:08,360 --> 00:23:11,040
the files associated with the channel, the meeting artifacts.

668
00:23:11,040 --> 00:23:13,240
If your governance model can't answer that cleanly,

669
00:23:13,240 --> 00:23:14,240
you don't have a model.

670
00:23:14,240 --> 00:23:15,440
You have a set of assumptions.

671
00:23:15,440 --> 00:23:17,400
Now layer guests on top of that topology.

672
00:23:17,400 --> 00:23:19,360
Most organizations need guests.

673
00:23:19,360 --> 00:23:22,120
The governance failure is not guests exist.

674
00:23:22,120 --> 00:23:23,800
The failure is treating guest access

675
00:23:23,800 --> 00:23:27,520
as a static setting rather than a lifecycle bound risk decision.

676
00:23:27,520 --> 00:23:30,160
Guests enter through a moment of urgency.

677
00:23:30,160 --> 00:23:32,800
A vendor needs access, a partner needs a file,

678
00:23:32,800 --> 00:23:34,760
a consultant needs to collaborate.

679
00:23:34,760 --> 00:23:36,720
The invite happens, the work gets done,

680
00:23:36,720 --> 00:23:38,200
then the org forgets to unwind it.

681
00:23:38,200 --> 00:23:40,840
Teams doesn't naturally force that unwinding.

682
00:23:40,840 --> 00:23:42,720
It gives you knobs, allow or block guests,

683
00:23:42,720 --> 00:23:44,760
restrict domains, limit capabilities.

684
00:23:44,760 --> 00:23:45,280
Fine.

685
00:23:45,280 --> 00:23:47,840
But the system still does the one thing you didn't design for.

686
00:23:47,840 --> 00:23:50,240
It preserves access until someone removes it.

687
00:23:50,240 --> 00:23:54,200
So guest access becomes permanent exposure by default.

688
00:23:54,200 --> 00:23:56,160
And because teams has multiple entry points

689
00:23:56,160 --> 00:23:57,640
for external collaboration,

690
00:23:57,640 --> 00:23:59,880
you end up with what looks like controlled external access

691
00:23:59,880 --> 00:24:03,040
in a policy document, but external reach in the real tenant.

692
00:24:03,040 --> 00:24:04,640
That reach includes guests,

693
00:24:04,640 --> 00:24:07,640
link-based sharing behind the team's share point site

694
00:24:07,640 --> 00:24:09,960
and content forwarded into other systems.

695
00:24:09,960 --> 00:24:11,360
Then comes ownership drift.

696
00:24:11,360 --> 00:24:13,160
This is the part that should make you tired

697
00:24:13,160 --> 00:24:14,400
because it's so predictable.

698
00:24:14,400 --> 00:24:16,960
Owners leave, they change roles, they get disabled,

699
00:24:16,960 --> 00:24:19,120
they go on parental leave, they move to a new division.

700
00:24:19,120 --> 00:24:21,760
The team remains, the channels remain, the guest remains,

701
00:24:21,760 --> 00:24:22,920
the files remain.

702
00:24:22,920 --> 00:24:25,440
If there is no enforced ownership reassignment,

703
00:24:25,440 --> 00:24:27,320
you now have a resource with authority,

704
00:24:27,320 --> 00:24:28,800
but no accountable human.

705
00:24:28,800 --> 00:24:31,200
And any governance process that depends on the owner

706
00:24:31,200 --> 00:24:33,200
to review access has already failed.

707
00:24:33,200 --> 00:24:34,120
Quietly.

708
00:24:34,120 --> 00:24:36,720
That's how teams becomes beyond control, though.

709
00:24:36,720 --> 00:24:38,320
Not because it can't be controlled,

710
00:24:38,320 --> 00:24:40,320
but because you didn't enforce the one primitive

711
00:24:40,320 --> 00:24:42,600
that makes control rootable ownership.

712
00:24:42,600 --> 00:24:43,800
And then there's life cycle.

713
00:24:43,800 --> 00:24:45,200
Teams gives you archiving.

714
00:24:45,200 --> 00:24:47,360
People love archiving because it feels like closure.

715
00:24:47,360 --> 00:24:48,840
Archive is not end of life.

716
00:24:48,840 --> 00:24:51,320
Archive is a state change in a collaboration UI.

717
00:24:51,320 --> 00:24:53,160
It does not automatically solve ownership.

718
00:24:53,160 --> 00:24:55,720
It does not necessarily solve external access.

719
00:24:55,720 --> 00:24:58,200
It does not necessarily solve share links.

720
00:24:58,200 --> 00:24:59,960
It does not necessarily solve the fact

721
00:24:59,960 --> 00:25:01,720
that the share point site is still there,

722
00:25:01,720 --> 00:25:03,440
still searchable based on permissions,

723
00:25:03,440 --> 00:25:06,120
still part of the tenant's content universe.

724
00:25:06,120 --> 00:25:08,520
So archiving becomes another governance illusion.

725
00:25:08,520 --> 00:25:10,320
The workspace feels done.

726
00:25:10,320 --> 00:25:11,960
Therefore, people stop thinking about it.

727
00:25:11,960 --> 00:25:13,120
The system keeps serving it.

728
00:25:13,120 --> 00:25:14,280
Now, about conditional access.

729
00:25:14,280 --> 00:25:16,560
Everyone wants conditional access to be the answer to everything

730
00:25:16,560 --> 00:25:17,960
because it's one of the few places

731
00:25:17,960 --> 00:25:19,360
where enforcement feels real.

732
00:25:19,360 --> 00:25:21,080
Conditional access is access-gating.

733
00:25:21,080 --> 00:25:22,520
It is not continuous governance.

734
00:25:22,520 --> 00:25:23,640
It evaluates a session.

735
00:25:23,640 --> 00:25:25,120
It does not manage life cycle.

736
00:25:25,120 --> 00:25:26,720
It does not clean up permission drift.

737
00:25:26,720 --> 00:25:28,440
It does not fix oneless resources.

738
00:25:28,440 --> 00:25:30,600
It does not stop someone with legitimate access

739
00:25:30,600 --> 00:25:32,760
from sharing content into a broader boundary.

740
00:25:32,760 --> 00:25:35,040
And when organizations try to use conditional access

741
00:25:35,040 --> 00:25:36,480
to compensate for governance gaps,

742
00:25:36,480 --> 00:25:38,320
they end up creating conditional chaos,

743
00:25:38,320 --> 00:25:39,880
a complex web of exceptions

744
00:25:39,880 --> 00:25:43,400
that turns deterministic intent into probabilistic behavior.

745
00:25:43,400 --> 00:25:45,840
Most people try to tighten policies but business breaks.

746
00:25:45,840 --> 00:25:47,200
Therefore, exceptions get added.

747
00:25:47,200 --> 00:25:49,520
Therefore, the policy becomes a negotiated document

748
00:25:49,520 --> 00:25:50,880
not an enforced boundary.

749
00:25:50,880 --> 00:25:52,840
So what do you actually control in teams

750
00:25:52,840 --> 00:25:54,560
if you want predictable outcomes?

751
00:25:54,560 --> 00:25:57,120
You control creation pathways, not by banning creation,

752
00:25:57,120 --> 00:25:58,960
but by forcing creation through a path

753
00:25:58,960 --> 00:26:02,800
that attaches ownership, classification, and life cycle up front.

754
00:26:02,800 --> 00:26:06,360
You control ownership, minimum owners, verified owners,

755
00:26:06,360 --> 00:26:09,200
and automated reassignment when owners disappear.

756
00:26:09,200 --> 00:26:11,840
You control external access, time-bound guests,

757
00:26:11,840 --> 00:26:14,640
review catences, and expiration that is enforced,

758
00:26:14,640 --> 00:26:16,000
not merely requested.

759
00:26:16,000 --> 00:26:17,320
And you control expiration.

760
00:26:17,320 --> 00:26:20,080
Teams and groups should not exist forever by accident.

761
00:26:20,080 --> 00:26:22,320
If nobody can justify the workspace on a schedule,

762
00:26:22,320 --> 00:26:24,880
it should degrade, escalate, and eventually die.

763
00:26:24,880 --> 00:26:28,160
Once you accept this, teams governance stops being a team's admin topic.

764
00:26:28,160 --> 00:26:30,320
It becomes data governance and life cycle governance

765
00:26:30,320 --> 00:26:31,680
with a chat front end.

766
00:26:31,680 --> 00:26:33,840
And now the dependency chain snaps into focus.

767
00:26:33,840 --> 00:26:35,920
Every team's failure becomes a share point failure

768
00:26:35,920 --> 00:26:37,160
because the data lives there.

769
00:26:37,160 --> 00:26:38,600
So let's follow the data.

770
00:26:38,600 --> 00:26:41,120
SharePoint is where drift becomes permanent.

771
00:26:41,120 --> 00:26:42,440
Erosion case two.

772
00:26:42,440 --> 00:26:44,520
SharePoint sharing drift is inevitable.

773
00:26:44,520 --> 00:26:47,520
SharePoint is where governance programs go to die quietly,

774
00:26:47,520 --> 00:26:50,080
because SharePoint is where workspace governance

775
00:26:50,080 --> 00:26:51,920
becomes file reality.

776
00:26:51,920 --> 00:26:55,640
And file reality is messy, emotional, and optimized for speed.

777
00:26:55,640 --> 00:26:58,920
A SharePoint site almost always starts its life in a known state.

778
00:26:58,920 --> 00:27:00,840
Someone provisions it from a template.

779
00:27:00,840 --> 00:27:02,320
It inherits the group membership.

780
00:27:02,320 --> 00:27:03,280
Maybe it gets a label.

781
00:27:03,280 --> 00:27:04,720
Maybe it has a retention policy.

782
00:27:04,720 --> 00:27:07,120
Maybe external sharing is controlled.

783
00:27:07,120 --> 00:27:08,360
Everyone feels good.

784
00:27:08,360 --> 00:27:09,720
The site is compliant.

785
00:27:09,720 --> 00:27:10,920
Then work begins.

786
00:27:10,920 --> 00:27:12,520
And drift begins with it.

787
00:27:12,520 --> 00:27:14,080
The drift mechanism is uncomplicated.

788
00:27:14,080 --> 00:27:16,200
It's human collaboration meeting a permission model

789
00:27:16,200 --> 00:27:18,040
that allows exceptions at every layer.

790
00:27:18,040 --> 00:27:20,320
A document gets shared because someone needs it now.

791
00:27:20,320 --> 00:27:23,000
A folder gets shared because the vendor can't find the file.

792
00:27:23,000 --> 00:27:24,760
A link gets created because it's faster

793
00:27:24,760 --> 00:27:26,760
than adding a guest and explaining teams.

794
00:27:26,760 --> 00:27:29,120
And none of those actions feel like governance decisions

795
00:27:29,120 --> 00:27:29,800
in the moment.

796
00:27:29,800 --> 00:27:31,520
They feel like work.

797
00:27:31,520 --> 00:27:34,040
Over time, those small decisions accumulate

798
00:27:34,040 --> 00:27:37,440
into a sharing model that no longer resembles the original intent.

799
00:27:37,440 --> 00:27:38,760
The site is still labeled.

800
00:27:38,760 --> 00:27:40,000
The site still has policies.

801
00:27:40,000 --> 00:27:42,240
The site still looks compliant in a dashboard,

802
00:27:42,240 --> 00:27:45,160
but access has drifted.

803
00:27:45,160 --> 00:27:47,080
Now here's where most people mess up.

804
00:27:47,080 --> 00:27:50,000
They treat SharePoint permissions as a site level control problem.

805
00:27:50,000 --> 00:27:52,640
They focus on membership and assume that's where access lives.

806
00:27:52,640 --> 00:27:53,120
It doesn't.

807
00:27:53,120 --> 00:27:55,760
Access lives in links, broken inheritance, and ad hoc grants.

808
00:27:55,760 --> 00:27:58,120
Broken inheritance is the long-lived exception factory.

809
00:27:58,120 --> 00:27:59,880
It exists because SharePoint allows you

810
00:27:59,880 --> 00:28:02,640
to break permission inheritance at the library, folder,

811
00:28:02,640 --> 00:28:03,960
and file level forever.

812
00:28:03,960 --> 00:28:05,680
Once you do it, you've created a branch

813
00:28:05,680 --> 00:28:08,280
in the authorization graph that will not heal itself.

814
00:28:08,280 --> 00:28:10,680
It will persist until someone deliberately unwinds it,

815
00:28:10,680 --> 00:28:14,120
which almost nobody does, because unwinding it requires context.

816
00:28:14,120 --> 00:28:16,240
And context is what SharePoint doesn't preserve.

817
00:28:16,240 --> 00:28:18,240
So you get a long tail of unique permissions

818
00:28:18,240 --> 00:28:20,160
that nobody can confidently delete.

819
00:28:20,160 --> 00:28:22,680
Every year that tail grows, every reorg makes it worse.

820
00:28:22,680 --> 00:28:24,840
Every just SharePoint creates another artifact,

821
00:28:24,840 --> 00:28:26,160
and then you get link types.

822
00:28:26,160 --> 00:28:29,560
Anyone links and company-wide links look like convenience features.

823
00:28:29,560 --> 00:28:32,320
Architecturally, they are blast radius modifiers.

824
00:28:32,320 --> 00:28:36,080
They change the access boundary from a known set of people to anyone

825
00:28:36,080 --> 00:28:38,680
who can obtain the URL or anyone in the tenant,

826
00:28:38,680 --> 00:28:41,400
regardless of whether they were ever meant to see the content.

827
00:28:41,400 --> 00:28:44,360
The platform encourages these links because they reduce friction.

828
00:28:44,360 --> 00:28:47,920
Governance fails because friction was the only thing preventing oversharing.

829
00:28:47,920 --> 00:28:49,840
The quiet danger is that link-based access

830
00:28:49,840 --> 00:28:52,080
doesn't look like a permission grant to most users.

831
00:28:52,080 --> 00:28:53,560
It looks like sending a URL.

832
00:28:53,560 --> 00:28:55,960
It feels temporary, it feels reversible in practice,

833
00:28:55,960 --> 00:28:58,800
it's durable, copyable, forwardable, and rarely reviewed.

834
00:28:58,800 --> 00:29:00,320
And you can add expiration, sure.

835
00:29:00,320 --> 00:29:01,840
But if you don't enforce expiration,

836
00:29:01,840 --> 00:29:04,440
you've just moved from permanent oversharing to oversharing

837
00:29:04,440 --> 00:29:07,520
until someone remembers to turn on the right settings everywhere.

838
00:29:07,520 --> 00:29:08,560
That's not a control model.

839
00:29:08,560 --> 00:29:09,720
That's hope with a calendar.

840
00:29:09,720 --> 00:29:11,240
Now sensitivity labels.

841
00:29:11,240 --> 00:29:13,760
This is where governance theatre becomes sophisticated

842
00:29:13,760 --> 00:29:16,560
because labels make people feel like they solve the problem.

843
00:29:16,560 --> 00:29:17,960
The file says confidential.

844
00:29:17,960 --> 00:29:20,080
And the site says highly confidential.

845
00:29:20,080 --> 00:29:21,600
The compliance team sees coverage.

846
00:29:21,600 --> 00:29:23,920
And none of that answers the only question that matters.

847
00:29:23,920 --> 00:29:25,600
Who can reach the content today?

848
00:29:25,600 --> 00:29:29,640
Labels are classification and depending on configuration protection.

849
00:29:29,640 --> 00:29:32,240
But they are not automatically access governance.

850
00:29:32,240 --> 00:29:34,240
A file can be labeled confidential

851
00:29:34,240 --> 00:29:36,280
and still be shared broadly inside the tenant

852
00:29:36,280 --> 00:29:38,200
or have an old link floating around

853
00:29:38,200 --> 00:29:41,880
or sit in a site where everyone is a member because that's how we work.

854
00:29:41,880 --> 00:29:45,360
This is why label coverage can rise while risk rises.

855
00:29:45,360 --> 00:29:46,560
You've improved metadata.

856
00:29:46,560 --> 00:29:48,280
You haven't improved access boundaries.

857
00:29:48,280 --> 00:29:50,240
Then there's the accumulated technical debt.

858
00:29:50,240 --> 00:29:53,760
Customizations, legacy patterns and half migrations.

859
00:29:53,760 --> 00:29:55,200
SharePoint has been around long enough

860
00:29:55,200 --> 00:29:56,920
that every org has a fossil record.

861
00:29:56,920 --> 00:29:58,880
Old sites with weird permission structures,

862
00:29:58,880 --> 00:30:00,720
libraries with bespoke workflows.

863
00:30:00,720 --> 00:30:03,440
External sharing rules that changed over time.

864
00:30:03,440 --> 00:30:07,000
Sites created under previous admin regimes with different defaults.

865
00:30:07,000 --> 00:30:08,480
This is not misconfiguration.

866
00:30:08,480 --> 00:30:10,400
This is architectural erosion.

867
00:30:10,400 --> 00:30:12,840
And it matters because co-pilot search and automation

868
00:30:12,840 --> 00:30:14,960
don't care which decade your site came from.

869
00:30:14,960 --> 00:30:17,000
They treat it as content with permissions.

870
00:30:17,000 --> 00:30:18,920
If access exists, it can be discovered.

871
00:30:18,920 --> 00:30:20,720
If it can be discovered, it can be used.

872
00:30:20,720 --> 00:30:22,600
So what's the governance reality in SharePoint?

873
00:30:22,600 --> 00:30:26,520
Sharing drift is inevitable because the platform permits drift at the point of work.

874
00:30:26,520 --> 00:30:28,520
Every exception pathway is a feature.

875
00:30:28,520 --> 00:30:31,200
Your job is not to stop humans from collaborating.

876
00:30:31,200 --> 00:30:33,400
Your job is to stop collaboration decisions

877
00:30:33,400 --> 00:30:35,320
from becoming permanent exposure.

878
00:30:35,320 --> 00:30:36,680
That requires three things.

879
00:30:36,680 --> 00:30:39,720
Constraint link types, time bound sharing by default,

880
00:30:39,720 --> 00:30:42,640
and force periodic attestation from accountable owners.

881
00:30:42,640 --> 00:30:44,400
And that last part is the real one

882
00:30:44,400 --> 00:30:47,280
because SharePoint will let your content survive forever.

883
00:30:47,280 --> 00:30:49,880
But it will also let your mistakes survive forever.

884
00:30:49,880 --> 00:30:51,480
And once you accept that, you stop asking,

885
00:30:51,480 --> 00:30:53,040
how do we make SharePoint compliant?

886
00:30:53,040 --> 00:30:56,920
You start asking, how do we keep SharePoint from quietly becoming public?

887
00:30:56,920 --> 00:30:58,560
One link at a time.

888
00:30:58,560 --> 00:31:00,520
SharePoint governance reality.

889
00:31:00,520 --> 00:31:02,360
Why label it doesn't fix it?

890
00:31:02,360 --> 00:31:05,400
This is the foundational misunderstanding and SharePoint governance.

891
00:31:05,400 --> 00:31:07,640
People think classification is governance.

892
00:31:07,640 --> 00:31:08,480
It isn't.

893
00:31:08,480 --> 00:31:11,440
A sensitivity label tells you what the content is supposed to be.

894
00:31:11,440 --> 00:31:14,360
It does not reliably tell you who can reach it today.

895
00:31:14,360 --> 00:31:16,120
And the moment you confuse those two,

896
00:31:16,120 --> 00:31:19,120
you build a compliance program that looks impressive in screenshots

897
00:31:19,120 --> 00:31:20,440
and collapses in discovery.

898
00:31:20,440 --> 00:31:23,640
Sensitivity labels at their best are transport protection.

899
00:31:23,640 --> 00:31:26,280
They can apply encryption, restrict sharing behavior,

900
00:31:26,280 --> 00:31:28,640
and persist protection when a file leaves SharePoint.

901
00:31:28,640 --> 00:31:29,240
That matters.

902
00:31:29,240 --> 00:31:31,880
It's one of the few mechanisms that can outlive the container.

903
00:31:31,880 --> 00:31:34,680
But labels are not a continuous access governance system.

904
00:31:34,680 --> 00:31:36,520
They don't repair broken inheritance.

905
00:31:36,520 --> 00:31:38,000
They don't recall old links.

906
00:31:38,000 --> 00:31:39,360
They don't remove shadow users.

907
00:31:39,360 --> 00:31:41,320
They don't expire broad internal access.

908
00:31:41,320 --> 00:31:44,240
They don't magically create an accountable owner

909
00:31:44,240 --> 00:31:46,920
who will make the ugly decision to remove someone's access.

910
00:31:46,920 --> 00:31:48,880
So the real question isn't, is it labeled?

911
00:31:48,880 --> 00:31:51,200
The real question is who can open it right now

912
00:31:51,200 --> 00:31:52,880
with the credentials they already have?

913
00:31:52,880 --> 00:31:54,320
And SharePoint answers that question

914
00:31:54,320 --> 00:31:56,680
through the permission graph, not the label catalog.

915
00:31:56,680 --> 00:31:58,120
Now here's where most people get trapped.

916
00:31:58,120 --> 00:31:59,080
They implement labels.

917
00:31:59,080 --> 00:32:00,000
They publish guidance.

918
00:32:00,000 --> 00:32:02,360
They measure coverage and they declare progress.

919
00:32:02,360 --> 00:32:05,240
Meanwhile, the sharing model continues to drift underneath them

920
00:32:05,240 --> 00:32:07,040
because users don't think in labels.

921
00:32:07,040 --> 00:32:08,040
They think in outcomes.

922
00:32:08,040 --> 00:32:09,400
Can this person get the file?

923
00:32:09,400 --> 00:32:11,000
So they use the fastest path.

924
00:32:11,000 --> 00:32:13,440
Links, folder shares, direct grants.

925
00:32:13,440 --> 00:32:14,760
Forwarded URLs.

926
00:32:14,760 --> 00:32:16,760
Sometimes the user doesn't even know they're creating

927
00:32:16,760 --> 00:32:18,440
a long-lived access object.

928
00:32:18,440 --> 00:32:19,920
They just clicked copy link.

929
00:32:19,920 --> 00:32:22,800
And because SharePoint makes it easy to create those access

930
00:32:22,800 --> 00:32:26,160
objects, you get a system where the metadata becomes more mature

931
00:32:26,160 --> 00:32:28,520
while the access boundary becomes more porous.

932
00:32:28,520 --> 00:32:30,440
That's why label it doesn't fix it.

933
00:32:30,440 --> 00:32:32,200
Because the label is not the enforcement plane.

934
00:32:32,200 --> 00:32:33,880
It's a tag with optional protection.

935
00:32:33,880 --> 00:32:35,400
And optional is not control.

936
00:32:35,400 --> 00:32:37,400
The next part that separates beginners from pros

937
00:32:37,400 --> 00:32:41,280
is understanding external sharing controls versus external reach.

938
00:32:41,280 --> 00:32:45,040
External sharing controls are tenant level and site level settings,

939
00:32:45,040 --> 00:32:47,440
which link types are allowed, whether guests are allowed,

940
00:32:47,440 --> 00:32:51,120
whether anonymous links are allowed, whether domains are restricted.

941
00:32:51,120 --> 00:32:54,000
External reach is what actually exists in your tenant today.

942
00:32:54,000 --> 00:32:57,480
Active guest accounts, shared links that already escaped,

943
00:32:57,480 --> 00:33:00,760
files shared from one drive into personal mailboxes,

944
00:33:00,760 --> 00:33:04,040
content copied into other systems, and company-wide links

945
00:33:04,040 --> 00:33:06,440
that effectively create internal exfiltration

946
00:33:06,440 --> 00:33:09,000
into the entire organization.

947
00:33:09,000 --> 00:33:12,120
You can clamp down settings today and still be exposed tomorrow

948
00:33:12,120 --> 00:33:14,040
because the exposure was created yesterday.

949
00:33:14,040 --> 00:33:17,280
And if you can't inventory yesterday, you can't control today.

950
00:33:17,280 --> 00:33:19,240
This is why the long tail is so dangerous.

951
00:33:19,240 --> 00:33:21,160
Often sites and stale permissions.

952
00:33:21,160 --> 00:33:22,640
Every tenant accumulates them.

953
00:33:22,640 --> 00:33:23,960
Every reogh adds them.

954
00:33:23,960 --> 00:33:25,600
Every M&A event multiplies them.

955
00:33:25,600 --> 00:33:27,360
Every will clean up later turns into,

956
00:33:27,360 --> 00:33:30,000
we don't know what this is, so we won't touch it.

957
00:33:30,000 --> 00:33:33,120
SharePoint is a perfect museum of organizational entropy.

958
00:33:33,120 --> 00:33:35,280
And Copilot is about to give everyone a guided tour.

959
00:33:35,280 --> 00:33:38,000
So governance, reality, and SharePoint looks like this.

960
00:33:38,000 --> 00:33:40,200
The only reliable control objectives

961
00:33:40,200 --> 00:33:42,320
are the ones that change what the system can do,

962
00:33:42,320 --> 00:33:43,480
not what the spreadsheet says.

963
00:33:43,480 --> 00:33:44,680
You control link types.

964
00:33:44,680 --> 00:33:47,400
You decide what default sharing means and you force it.

965
00:33:47,400 --> 00:33:49,240
You do not allow anyone links,

966
00:33:49,240 --> 00:33:51,920
unless you accept what that phrase literally means.

967
00:33:51,920 --> 00:33:53,440
You control expiration.

968
00:33:53,440 --> 00:33:55,080
Not we recommend expiry.

969
00:33:55,080 --> 00:33:57,560
Default expiry, enforced expiry.

970
00:33:57,560 --> 00:34:00,560
With a business process that renews access intentionally,

971
00:34:00,560 --> 00:34:02,640
instead of letting it persist by accident.

972
00:34:02,640 --> 00:34:04,160
You control owner at his stations.

973
00:34:04,160 --> 00:34:05,720
Owners must periodically certify,

974
00:34:05,720 --> 00:34:07,040
yes, this site still matters.

975
00:34:07,040 --> 00:34:08,720
Yes, these broad links still make sense.

976
00:34:08,720 --> 00:34:11,040
Yes, these external users still belong.

977
00:34:11,040 --> 00:34:12,600
And if they don't respond, you escalate.

978
00:34:12,600 --> 00:34:14,480
If escalation fails, you degrade access.

979
00:34:14,480 --> 00:34:16,400
If degradation fails, you expire.

980
00:34:16,400 --> 00:34:17,880
You control life cycle triggers.

981
00:34:17,880 --> 00:34:19,560
Site created for a project.

982
00:34:19,560 --> 00:34:21,560
Then the end of the project must trigger review

983
00:34:21,560 --> 00:34:23,120
and archival or deletion.

984
00:34:23,120 --> 00:34:24,800
Archive should be a governance action

985
00:34:24,800 --> 00:34:26,840
with consequences, not a UI state

986
00:34:26,840 --> 00:34:28,960
that makes people feel better.

987
00:34:28,960 --> 00:34:31,200
And you control remediation of stale permissions.

988
00:34:31,200 --> 00:34:34,200
Deleted users, disabled users, and shadow grants

989
00:34:34,200 --> 00:34:37,080
should not sit in place for years waiting for a human to notice.

990
00:34:37,080 --> 00:34:38,120
That is not governance.

991
00:34:38,120 --> 00:34:39,960
That is archaeological risk management.

992
00:34:39,960 --> 00:34:42,600
Now, the reason this works is that it turns governance

993
00:34:42,600 --> 00:34:44,320
into a continuous circuit.

994
00:34:44,320 --> 00:34:46,680
Detect root, remediate, prove.

995
00:34:46,680 --> 00:34:48,360
Not label and hope.

996
00:34:48,360 --> 00:34:50,120
And once you get honest about SharePoint,

997
00:34:50,120 --> 00:34:52,120
you start seeing the next failure pattern.

998
00:34:52,120 --> 00:34:54,480
The sharing model doesn't stay inside SharePoint.

999
00:34:54,480 --> 00:34:56,240
It leaks into one drive by design,

1000
00:34:56,240 --> 00:34:58,680
and then automation shows up and industrializes it.

1001
00:34:58,680 --> 00:35:00,040
Because the most dangerous permission

1002
00:35:00,040 --> 00:35:02,160
in Microsoft 365 isn't owner.

1003
00:35:02,160 --> 00:35:05,240
It can automate access to data nobody remembers exists.

1004
00:35:05,240 --> 00:35:09,120
Erosion case three, power automate as a data expiltration fabric.

1005
00:35:09,120 --> 00:35:12,000
Power automate is where governance stops pretending.

1006
00:35:12,000 --> 00:35:15,000
Because once you allow automation, you've moved past who

1007
00:35:15,000 --> 00:35:18,440
can access data and into what can move data, where,

1008
00:35:18,440 --> 00:35:19,840
and under which identity.

1009
00:35:19,840 --> 00:35:21,240
And most tenants have no idea.

1010
00:35:21,240 --> 00:35:24,240
This erosion pattern usually starts innocently.

1011
00:35:24,240 --> 00:35:26,880
A user builds a helper flow to save time,

1012
00:35:26,880 --> 00:35:30,080
send an email when a form is submitted, copy an attachment

1013
00:35:30,080 --> 00:35:33,320
to a folder, notify a channel when something changes.

1014
00:35:33,320 --> 00:35:35,360
It's helpful, it works, and it feels harmless.

1015
00:35:35,360 --> 00:35:36,440
Then it becomes relied on.

1016
00:35:36,440 --> 00:35:37,960
Then it becomes business process,

1017
00:35:37,960 --> 00:35:40,040
without ever becoming governed.

1018
00:35:40,040 --> 00:35:41,600
That's the first failure mode.

1019
00:35:41,600 --> 00:35:43,920
Flows become production systems without review

1020
00:35:43,920 --> 00:35:46,120
because the platform makes publishing frictionless.

1021
00:35:46,120 --> 00:35:48,440
There's no architectural moment where the system forces you

1022
00:35:48,440 --> 00:35:50,760
to say, this is now operational software.

1023
00:35:50,760 --> 00:35:52,240
It just runs.

1024
00:35:52,240 --> 00:35:54,120
And because it runs, people trust it.

1025
00:35:54,120 --> 00:35:55,560
Now here's where most people mess up.

1026
00:35:55,560 --> 00:35:57,920
They treat power automate as low code,

1027
00:35:57,920 --> 00:36:00,160
and assume low code means low risk.

1028
00:36:00,160 --> 00:36:01,800
Risk isn't about how the thing is built.

1029
00:36:01,800 --> 00:36:03,280
Risk is about what it can reach.

1030
00:36:03,280 --> 00:36:05,360
And flows can reach almost everything.

1031
00:36:05,360 --> 00:36:08,000
Connectors Brawl is the next predictable outcome.

1032
00:36:08,000 --> 00:36:10,280
Organizations talk about sanctioned connectors

1033
00:36:10,280 --> 00:36:11,920
like it's a solved boundary.

1034
00:36:11,920 --> 00:36:13,320
Microsoft connectors are safe.

1035
00:36:13,320 --> 00:36:14,640
Third party connectors are risky.

1036
00:36:14,640 --> 00:36:15,760
Block the risky ones.

1037
00:36:15,760 --> 00:36:16,640
That's a comforting story.

1038
00:36:16,640 --> 00:36:17,880
It's also incomplete.

1039
00:36:17,880 --> 00:36:19,920
The real risk comes from sanctioned connectors

1040
00:36:19,920 --> 00:36:21,280
used in unsanctioned ways.

1041
00:36:21,280 --> 00:36:22,760
Outlook is sanctioned.

1042
00:36:22,760 --> 00:36:23,720
So is SharePoint.

1043
00:36:23,720 --> 00:36:24,600
So is OneDrive.

1044
00:36:24,600 --> 00:36:26,120
So is Teams.

1045
00:36:26,120 --> 00:36:28,560
So is HTTP depending on what you allow.

1046
00:36:28,560 --> 00:36:31,200
So is any connector that can take content out of a controlled

1047
00:36:31,200 --> 00:36:32,720
boundary and push it somewhere else.

1048
00:36:32,720 --> 00:36:35,520
A flow that reads from SharePoint and emails a file

1049
00:36:35,520 --> 00:36:38,000
to a personal mailbox is X-Filtration.

1050
00:36:38,000 --> 00:36:39,720
A flow that reads from a labeled library

1051
00:36:39,720 --> 00:36:43,320
and drops content into an unmanaged location is X-Filtration.

1052
00:36:43,320 --> 00:36:45,440
A flow that iterates a list and posts

1053
00:36:45,440 --> 00:36:47,800
the results into a chat is X-Filtration

1054
00:36:47,800 --> 00:36:49,320
if the audience boundary is wrong.

1055
00:36:49,320 --> 00:36:50,760
The system doesn't know intent.

1056
00:36:50,760 --> 00:36:52,760
It only knows that the connectors allow it.

1057
00:36:52,760 --> 00:36:54,400
High-risk paths are not exotic.

1058
00:36:54,400 --> 00:36:55,360
They're boring.

1059
00:36:55,360 --> 00:37:00,000
Email.httpcalls.file exports, third party SAS destinations,

1060
00:37:00,000 --> 00:37:04,120
anything that turns data at rest in M365 into data in motion

1061
00:37:04,120 --> 00:37:06,240
outside the tenant's governed boundary.

1062
00:37:06,240 --> 00:37:08,400
And the thing that makes this dangerous at scale

1063
00:37:08,400 --> 00:37:11,240
is that flows don't need to be malicious to cause harm.

1064
00:37:11,240 --> 00:37:12,560
They just need to be convenient.

1065
00:37:12,560 --> 00:37:14,920
A maker solves a local problem and accidentally

1066
00:37:14,920 --> 00:37:16,160
creates a global leak.

1067
00:37:16,160 --> 00:37:17,680
Now, the most misunderstood part--

1068
00:37:17,680 --> 00:37:19,640
credential ambiguity.

1069
00:37:19,640 --> 00:37:21,560
People assume flows run as the user.

1070
00:37:21,560 --> 00:37:22,560
They often don't.

1071
00:37:22,560 --> 00:37:24,400
Sometimes they run under the author's connection.

1072
00:37:24,400 --> 00:37:26,680
Sometimes they run under a shared service account.

1073
00:37:26,680 --> 00:37:28,360
Sometimes they run under a connector

1074
00:37:28,360 --> 00:37:31,440
that has broader privileges than the person who triggered the flow.

1075
00:37:31,440 --> 00:37:33,280
Sometimes they run as a run-only user,

1076
00:37:33,280 --> 00:37:36,160
but execute actions using the creator's connection.

1077
00:37:36,160 --> 00:37:38,080
So you end up with an authorization model

1078
00:37:38,080 --> 00:37:40,680
that is not deterministic from the user's perspective.

1079
00:37:40,680 --> 00:37:42,480
A person clicks a button, but the flow

1080
00:37:42,480 --> 00:37:44,280
executes with someone else's privileges.

1081
00:37:44,280 --> 00:37:46,040
That distinction matters because now you've

1082
00:37:46,040 --> 00:37:48,440
created a shadow-privileged escalation pathway

1083
00:37:48,440 --> 00:37:50,360
that doesn't look like privilege escalation.

1084
00:37:50,360 --> 00:37:51,640
It looks like automation.

1085
00:37:51,640 --> 00:37:53,640
And you can tell yourself you'll audit it.

1086
00:37:53,640 --> 00:37:56,200
But audits miss it because flows hide in volume

1087
00:37:56,200 --> 00:37:57,600
and fragmented ownership.

1088
00:37:57,600 --> 00:37:59,280
Power automated states grow fast.

1089
00:37:59,280 --> 00:38:01,360
People create flows in the default environment.

1090
00:38:01,360 --> 00:38:02,840
They create them in teams.

1091
00:38:02,840 --> 00:38:04,440
They create them as part of templates.

1092
00:38:04,440 --> 00:38:05,200
They copy them.

1093
00:38:05,200 --> 00:38:05,920
They fork them.

1094
00:38:05,920 --> 00:38:07,080
They abandon them.

1095
00:38:07,080 --> 00:38:09,600
And the platform does not force ownership hygiene.

1096
00:38:09,600 --> 00:38:12,200
So you end up with the same silent killer from earlier,

1097
00:38:12,200 --> 00:38:14,480
just in automation form, ownerless flows.

1098
00:38:14,480 --> 00:38:16,840
When the maker leaves, the flow doesn't necessarily stop.

1099
00:38:16,840 --> 00:38:18,080
It just becomes unaccountable.

1100
00:38:18,080 --> 00:38:21,160
It continues to run, continuing to move data,

1101
00:38:21,160 --> 00:38:22,960
with nobody responsible for the behavior.

1102
00:38:22,960 --> 00:38:23,920
That's not hypothetical.

1103
00:38:23,920 --> 00:38:25,520
That's how the platform behaves.

1104
00:38:25,520 --> 00:38:27,920
And the native visibility is structurally fragmented.

1105
00:38:27,920 --> 00:38:30,280
Admins can see some things in the power platform

1106
00:38:30,280 --> 00:38:32,480
admin center, some things in purview,

1107
00:38:32,480 --> 00:38:34,760
some things in audit logs, and some things only

1108
00:38:34,760 --> 00:38:36,920
when someone opens the flow and notices.

1109
00:38:36,920 --> 00:38:38,560
That's not a unified risk model.

1110
00:38:38,560 --> 00:38:39,560
That's a scavenger hunt.

1111
00:38:39,560 --> 00:38:42,320
So power automate becomes a data-exfiltration fabric,

1112
00:38:42,320 --> 00:38:43,880
not because it's evil, but because it's

1113
00:38:43,880 --> 00:38:46,600
an automation layer attached to a permission model

1114
00:38:46,600 --> 00:38:50,360
that was never designed to be continuously verified at scale.

1115
00:38:50,360 --> 00:38:53,720
If you're relying on approved makers and periodic reviews,

1116
00:38:53,720 --> 00:38:56,120
you've already accepted a probabilistic outcome.

1117
00:38:56,120 --> 00:38:56,960
You'll catch some.

1118
00:38:56,960 --> 00:38:58,160
You'll miss some.

1119
00:38:58,160 --> 00:39:01,160
And the ones you miss will be the ones that quietly root data

1120
00:39:01,160 --> 00:39:02,880
out of the boundary you thought you had.

1121
00:39:02,880 --> 00:39:06,040
Now, the system does have a control primitive here, DLP.

1122
00:39:06,040 --> 00:39:08,560
But DLP, without context, is its own trap.

1123
00:39:08,560 --> 00:39:09,800
And that's next.

1124
00:39:09,800 --> 00:39:11,440
Power automate governance reality.

1125
00:39:11,440 --> 00:39:13,880
DLP, without context, is a trap.

1126
00:39:13,880 --> 00:39:16,400
DLP is the control Microsoft gives you

1127
00:39:16,400 --> 00:39:18,720
when power automate starts scaring people.

1128
00:39:18,720 --> 00:39:19,680
And yes, you need it.

1129
00:39:19,680 --> 00:39:20,720
But here's the problem.

1130
00:39:20,720 --> 00:39:23,600
Most organizations treat DLP like a risk model.

1131
00:39:23,600 --> 00:39:25,320
It isn't DLP is a boundary tool.

1132
00:39:25,320 --> 00:39:27,280
It categorizes connectors and decides

1133
00:39:27,280 --> 00:39:29,240
which combinations can coexist.

1134
00:39:29,240 --> 00:39:31,040
It can block obvious bad patterns.

1135
00:39:31,040 --> 00:39:33,080
It can stop the laziest form of exfiltration.

1136
00:39:33,080 --> 00:39:35,760
It can prevent copy from SharePoint to Dropbox

1137
00:39:35,760 --> 00:39:38,000
if you've decided Dropbox is outside the fence.

1138
00:39:38,000 --> 00:39:38,800
That's useful.

1139
00:39:38,800 --> 00:39:40,920
But it's not governance because it has no context

1140
00:39:40,920 --> 00:39:42,840
of intent, scale, or consequence.

1141
00:39:42,840 --> 00:39:44,360
Here's what DLP actually knows.

1142
00:39:44,360 --> 00:39:47,280
Connector A, talk to Connector B in Environment X.

1143
00:39:47,280 --> 00:39:48,280
Under policy Y.

1144
00:39:48,280 --> 00:39:50,280
It does not know whether the data was sensitive.

1145
00:39:50,280 --> 00:39:52,480
It does not know whether the destination was appropriate

1146
00:39:52,480 --> 00:39:53,720
for the business process.

1147
00:39:53,720 --> 00:39:56,160
It does not know whether the flow runs once a year

1148
00:39:56,160 --> 00:39:57,600
or 10,000 times a day.

1149
00:39:57,600 --> 00:39:59,760
It does not know whether the flow is owned by someone

1150
00:39:59,760 --> 00:40:02,080
accountable or abandoned by someone who left.

1151
00:40:02,080 --> 00:40:05,400
So if you use DLP as your primary governance layer,

1152
00:40:05,400 --> 00:40:07,360
you will do the thing every organization does.

1153
00:40:07,360 --> 00:40:08,360
You will overblock.

1154
00:40:08,360 --> 00:40:11,320
You block broadly because you're trying to reduce risk quickly.

1155
00:40:11,320 --> 00:40:13,280
The business breaks because the platform was actually

1156
00:40:13,280 --> 00:40:14,800
being used for real work.

1157
00:40:14,800 --> 00:40:16,920
Then you create exceptions to unblock the work.

1158
00:40:16,920 --> 00:40:18,520
Those exceptions don't stay small.

1159
00:40:18,520 --> 00:40:19,560
They multiply.

1160
00:40:19,560 --> 00:40:21,800
Every exception is justified in isolation.

1161
00:40:21,800 --> 00:40:23,360
This team needs this connector.

1162
00:40:23,360 --> 00:40:25,840
This department can't function without that integration.

1163
00:40:25,840 --> 00:40:27,240
We'll review it later.

1164
00:40:27,240 --> 00:40:28,800
And then later never arrives because you

1165
00:40:28,800 --> 00:40:30,360
didn't design the review loop.

1166
00:40:30,360 --> 00:40:31,440
This is the failure.

1167
00:40:31,440 --> 00:40:32,920
Broadblocks create friction.

1168
00:40:32,920 --> 00:40:34,440
Friction creates escalation.

1169
00:40:34,440 --> 00:40:35,920
Escalation creates exceptions.

1170
00:40:35,920 --> 00:40:38,360
And exceptions convert your deterministic boundary

1171
00:40:38,360 --> 00:40:40,280
into a probabilistic one.

1172
00:40:40,280 --> 00:40:41,680
That is not misconfiguration.

1173
00:40:41,680 --> 00:40:43,720
That is architectural erosion.

1174
00:40:43,720 --> 00:40:46,840
And DLP accelerates it when you treat it like a yes-no switch

1175
00:40:46,840 --> 00:40:49,120
rather than a risk-scored system.

1176
00:40:49,120 --> 00:40:51,520
Now here's the more subtle trap, low signal findings.

1177
00:40:51,520 --> 00:40:54,480
A DLP violation looks urgent because it's a violation.

1178
00:40:54,480 --> 00:40:57,520
But the platform can produce thousands of equally urgent events

1179
00:40:57,520 --> 00:40:58,720
with no hierarchy.

1180
00:40:58,720 --> 00:41:01,360
Once everything looks like a fire, nobody fights fires.

1181
00:41:01,360 --> 00:41:02,880
They triage by annoyance.

1182
00:41:02,880 --> 00:41:06,080
So the team focuses on what breaks loudly, not what leaks quietly.

1183
00:41:06,080 --> 00:41:08,320
And that means the highest risk flows often

1184
00:41:08,320 --> 00:41:10,400
survive because they're operationally stable.

1185
00:41:10,400 --> 00:41:10,880
They run.

1186
00:41:10,880 --> 00:41:11,480
They don't error.

1187
00:41:11,480 --> 00:41:12,800
They don't call the help desk.

1188
00:41:12,800 --> 00:41:14,040
They just move data.

1189
00:41:14,040 --> 00:41:15,800
So DLP becomes a theater prop.

1190
00:41:15,800 --> 00:41:17,040
You can say you have DLP.

1191
00:41:17,040 --> 00:41:18,040
You can show policies.

1192
00:41:18,040 --> 00:41:19,240
You can show categories.

1193
00:41:19,240 --> 00:41:20,760
You can show blocked connectors.

1194
00:41:20,760 --> 00:41:23,040
And you can still have high-risk X filtration

1195
00:41:23,040 --> 00:41:25,800
because the dangerous parts are inside the allowed boundary.

1196
00:41:25,800 --> 00:41:26,440
Think about this.

1197
00:41:26,440 --> 00:41:28,520
Outlook is allowed in almost every tenant.

1198
00:41:28,520 --> 00:41:29,680
SharePoint is allowed.

1199
00:41:29,680 --> 00:41:30,760
One drive is allowed.

1200
00:41:30,760 --> 00:41:32,320
Teams is allowed.

1201
00:41:32,320 --> 00:41:34,200
If those connectors can be combined,

1202
00:41:34,200 --> 00:41:36,800
you can build a flow that moves sensitive data

1203
00:41:36,800 --> 00:41:39,720
into email, into chat, into personal storage,

1204
00:41:39,720 --> 00:41:42,880
into places where retention and access behave differently

1205
00:41:42,880 --> 00:41:44,120
than you intended.

1206
00:41:44,120 --> 00:41:44,960
DLP didn't fail.

1207
00:41:44,960 --> 00:41:46,960
Your risk model failed because you never built one.

1208
00:41:46,960 --> 00:41:49,440
So what actually matters when you want to govern power automate?

1209
00:41:49,440 --> 00:41:50,320
Three inputs.

1210
00:41:50,320 --> 00:41:52,600
Data source sensitivity, destination, and scale.

1211
00:41:52,600 --> 00:41:56,240
Data source sensitivity is not, does the flow use SharePoint?

1212
00:41:56,240 --> 00:41:59,160
It's which site, which library, what classification,

1213
00:41:59,160 --> 00:42:01,640
and what permissions exist around that data?

1214
00:42:01,640 --> 00:42:04,560
If you can't map the flow's inputs to actual content risk,

1215
00:42:04,560 --> 00:42:05,560
you're blind.

1216
00:42:05,560 --> 00:42:07,880
Destination is not, is the connector approved.

1217
00:42:07,880 --> 00:42:10,760
So it's does the destination expand the audience boundary?

1218
00:42:10,760 --> 00:42:12,600
Email expands boundaries.

1219
00:42:12,600 --> 00:42:14,200
HTTP expands boundaries.

1220
00:42:14,200 --> 00:42:16,480
Export to file expands boundaries.

1221
00:42:16,480 --> 00:42:19,600
Even posting into a large Teams channel expands boundaries

1222
00:42:19,600 --> 00:42:21,360
if the channel membership is messy.

1223
00:42:21,360 --> 00:42:22,640
Scale is the multiplier.

1224
00:42:22,640 --> 00:42:24,840
A risky flow that runs once is a bad idea.

1225
00:42:24,840 --> 00:42:27,600
A risky flow that runs continuously is a leak engine.

1226
00:42:27,600 --> 00:42:30,680
And most tenants have no ability to distinguish those two quickly

1227
00:42:30,680 --> 00:42:32,320
because they don't inventory flows

1228
00:42:32,320 --> 00:42:34,360
with operational metadata and ownership.

1229
00:42:34,360 --> 00:42:37,000
So the control objectives are not block these connectors.

1230
00:42:37,000 --> 00:42:39,560
The control objectives are inventory, ownership,

1231
00:42:39,560 --> 00:42:42,120
tiered environments, and least privilege execution.

1232
00:42:42,120 --> 00:42:45,160
Inventory means you know what flows exist, where they live,

1233
00:42:45,160 --> 00:42:47,440
what connectors they use, and what they touch.

1234
00:42:47,440 --> 00:42:48,680
Not a one-time export.

1235
00:42:48,680 --> 00:42:50,080
A continuously updated view.

1236
00:42:50,080 --> 00:42:53,000
Ownership means every flow has someone accountable.

1237
00:42:53,000 --> 00:42:54,720
And the moment that person disappears,

1238
00:42:54,720 --> 00:42:58,440
the flow is forced into review, reassignment, or retirement.

1239
00:42:58,440 --> 00:43:00,160
Ownerless automation is unacceptable

1240
00:43:00,160 --> 00:43:01,840
because automation without accountability

1241
00:43:01,840 --> 00:43:04,840
is just a machine doing things nobody will explain to an auditor.

1242
00:43:04,840 --> 00:43:06,800
Tiered environments means you stop pretending

1243
00:43:06,800 --> 00:43:08,960
the default environment is a safe place to build.

1244
00:43:08,960 --> 00:43:11,080
The default environment is a governance sinkhole

1245
00:43:11,080 --> 00:43:13,480
because it's where everything goes when you didn't design a home.

1246
00:43:13,480 --> 00:43:16,000
Real governance means development environments,

1247
00:43:16,000 --> 00:43:18,840
controlled promotion paths, and boundaries that reflect risk.

1248
00:43:18,840 --> 00:43:21,520
And least privilege execution means you stop allowing flows

1249
00:43:21,520 --> 00:43:23,600
to run under ambiguous identities.

1250
00:43:23,600 --> 00:43:25,720
You design for explicit run contexts

1251
00:43:25,720 --> 00:43:28,440
with credentials that are reviewable and expirable,

1252
00:43:28,440 --> 00:43:29,840
not shared and forgotten.

1253
00:43:29,840 --> 00:43:32,880
Now the system law, DLP is necessary, but it is not sufficient.

1254
00:43:32,880 --> 00:43:35,440
If you rely on it alone, you will either cripple the business

1255
00:43:35,440 --> 00:43:37,040
or drown in exceptions.

1256
00:43:37,040 --> 00:43:40,400
If you combine it with ownership, inventory, and risk prioritization,

1257
00:43:40,400 --> 00:43:42,640
it becomes one layer in a real control plane.

1258
00:43:42,640 --> 00:43:45,480
And once you accept that, you're ready for the next multiplier,

1259
00:43:45,480 --> 00:43:49,040
copilot, because copilot doesn't just reveal your permission mistakes,

1260
00:43:49,040 --> 00:43:51,880
it speeds up every mistake you've already automated.

1261
00:43:51,880 --> 00:43:56,600
Erosion case four, copilot doesn't create risk, it reveals it.

1262
00:43:56,600 --> 00:43:58,560
Copilot doesn't create new risk categories.

1263
00:43:58,560 --> 00:44:00,720
It doesn't magically invent new permissions.

1264
00:44:00,720 --> 00:44:03,920
It doesn't open doors that were locked, it just turns the lights on.

1265
00:44:03,920 --> 00:44:07,840
And the reason that feels like a security incident is because most tenants

1266
00:44:07,840 --> 00:44:11,160
have been operating in the dark for years, relying on friction and obscurity

1267
00:44:11,160 --> 00:44:12,280
as a control mechanism.

1268
00:44:12,280 --> 00:44:13,600
That mechanism is now dead.

1269
00:44:13,600 --> 00:44:17,320
Copilot is a discovery interface for your existing authorization graph.

1270
00:44:17,320 --> 00:44:20,080
Whatever a user can reach through normal access rules,

1271
00:44:20,080 --> 00:44:23,800
copilot can summarize, correlate, and surface at conversational speed.

1272
00:44:23,800 --> 00:44:25,680
The platform did not change your permissions.

1273
00:44:25,680 --> 00:44:29,000
The platform changed the cost of finding what those permissions already allow.

1274
00:44:29,000 --> 00:44:32,560
So the first copilot risk isn't AI, it's surprise.

1275
00:44:32,560 --> 00:44:35,880
An employee asks a normal question and copilot produces an answer

1276
00:44:35,880 --> 00:44:38,640
that includes a document from a site they didn't even know existed.

1277
00:44:38,640 --> 00:44:41,920
They technically had access, they just never had a reason to go looking.

1278
00:44:41,920 --> 00:44:45,960
That file sat in the corner of the tenant like a forgotten chemical drum in the back of a warehouse.

1279
00:44:45,960 --> 00:44:47,960
Copilot didn't spill it.

1280
00:44:47,960 --> 00:44:50,560
Copilot put a label on it and handed it to someone.

1281
00:44:50,560 --> 00:44:53,480
This is why the phrase copilot readiness is mostly a lie.

1282
00:44:53,480 --> 00:44:55,200
Not because readiness is impossible,

1283
00:44:55,200 --> 00:44:58,600
but because most organizations interpret readiness as a cleanup sprint

1284
00:44:58,600 --> 00:45:00,720
will roll it out, then we'll fix permissions.

1285
00:45:00,720 --> 00:45:01,920
That's backwards.

1286
00:45:01,920 --> 00:45:04,360
Because copilot collapses time to exposure,

1287
00:45:04,360 --> 00:45:09,080
what you use to discover after months of drift and a lucky audit gets discovered in a day

1288
00:45:09,080 --> 00:45:13,480
by normal users in normal workflows with no malicious intent.

1289
00:45:13,480 --> 00:45:16,520
AI turns hard to find into one prompt away.

1290
00:45:16,520 --> 00:45:18,120
That distinction matters.

1291
00:45:18,120 --> 00:45:22,320
Before copilot, a messy tenant could still function because discovery had a cost.

1292
00:45:22,320 --> 00:45:25,600
Users needed to know where to look, they needed to stumble into the right team,

1293
00:45:25,600 --> 00:45:28,840
they needed to remember the site name, they needed to ask someone,

1294
00:45:28,840 --> 00:45:32,440
and those steps acted as informal friction, copilot removes the friction.

1295
00:45:32,440 --> 00:45:34,120
Now the second trap, wrongness.

1296
00:45:34,120 --> 00:45:37,520
Copilot isn't only a security story, it's also a trust story.

1297
00:45:37,520 --> 00:45:40,160
The wrong answer is not usually caused by hallucination.

1298
00:45:40,160 --> 00:45:44,680
Most of the time the wrong answer is caused by correct retrieval from obsolete data.

1299
00:45:44,680 --> 00:45:47,280
Duplicate versions, drafts that were never deleted,

1300
00:45:47,280 --> 00:45:49,360
old policy documents that still exist,

1301
00:45:49,360 --> 00:45:50,960
sites that should have been archived,

1302
00:45:50,960 --> 00:45:54,960
teams created for a project that ended three years ago but still have permissive access.

1303
00:45:54,960 --> 00:45:58,280
So the risk becomes organizational decision making based on stale truth

1304
00:45:58,280 --> 00:46:02,320
and your controls won't catch that because compliance tools are not relevance tools.

1305
00:46:02,320 --> 00:46:04,600
Retention is not curation, labels are not truth.

1306
00:46:04,600 --> 00:46:07,720
Copilot will confidently summarize whatever it can access.

1307
00:46:07,720 --> 00:46:10,280
If the data state is messy, the output will be messy.

1308
00:46:10,280 --> 00:46:13,760
That's not copilot misbehaving, that's copilot reflecting your tenant.

1309
00:46:13,760 --> 00:46:17,680
This clicked for a lot of people the first time they saw copilot quote a document

1310
00:46:17,680 --> 00:46:19,400
that everyone forgot about.

1311
00:46:19,400 --> 00:46:21,120
They didn't suddenly become insecure.

1312
00:46:21,120 --> 00:46:24,840
They were always insecure, they just stopped being able to hide behind chaos.

1313
00:46:24,840 --> 00:46:28,960
Now add the compounding effect, every new workspace is now a new knowledge surface.

1314
00:46:28,960 --> 00:46:32,640
Every team created without life cycle becomes a permanent search target.

1315
00:46:32,640 --> 00:46:36,680
Every sharepoint side with broken inheritance becomes a future copilot source.

1316
00:46:36,680 --> 00:46:40,160
Everyone drive linked that never expired becomes a retrieval pathway.

1317
00:46:40,160 --> 00:46:43,800
Every flow that copies data into the wrong place becomes an amplifier

1318
00:46:43,800 --> 00:46:47,440
because it increases the volume of discoverable content in that location.

1319
00:46:47,440 --> 00:46:50,800
Copilot doesn't just reveal drift, it rewards drift by making it useful.

1320
00:46:50,800 --> 00:46:52,880
That's why the readiness myth is so dangerous.

1321
00:46:52,880 --> 00:46:56,400
We'll clean up after rollout is really, we'll let AI scale our mistakes

1322
00:46:56,400 --> 00:46:58,040
and then try to unscale them.

1323
00:46:58,040 --> 00:46:59,040
That doesn't work.

1324
00:46:59,040 --> 00:47:01,480
Because once users start relying on copilot outputs,

1325
00:47:01,480 --> 00:47:03,360
the mess becomes operationally embedded.

1326
00:47:03,360 --> 00:47:06,800
People build workflows around the answers they get, teams create habits.

1327
00:47:06,800 --> 00:47:08,400
And now you're not just cleaning permissions,

1328
00:47:08,400 --> 00:47:12,720
you're cleaning cultural dependency on a system that's consuming an uncurated data state.

1329
00:47:12,720 --> 00:47:15,920
And then you get the quietest failure, governance by embarrassment.

1330
00:47:15,920 --> 00:47:19,600
Organizations start treating copilot incidents as user mistakes.

1331
00:47:19,600 --> 00:47:21,800
Don't ask that, be careful what you prompt.

1332
00:47:21,800 --> 00:47:25,640
Use better phrasing, that's the same governance theater, just with new vocabulary.

1333
00:47:25,640 --> 00:47:27,640
Prompt discipline is not a control plane.

1334
00:47:27,640 --> 00:47:32,240
The control plane is still ownership, life cycle, and enforced access boundaries.

1335
00:47:32,240 --> 00:47:34,760
Copilot just makes the absence of those primitives obvious.

1336
00:47:34,760 --> 00:47:38,560
So the real copilot governance question is not how do we configure copilot?

1337
00:47:38,560 --> 00:47:41,560
It's what is copilot allowed to see and do we actually mean that?

1338
00:47:41,560 --> 00:47:43,960
If you can't answer that, you shouldn't roll it out broadly.

1339
00:47:43,960 --> 00:47:47,360
Not because copilot is unsafe, but because your tenant is unsupervised.

1340
00:47:47,360 --> 00:47:49,920
And the final point, because it sets up what comes next,

1341
00:47:49,920 --> 00:47:52,840
copilot doesn't just surface content, it accelerates creation,

1342
00:47:52,840 --> 00:47:54,680
it makes it easier to generate documents,

1343
00:47:54,680 --> 00:47:57,960
build flows, build agents, and spin up new workspaces.

1344
00:47:57,960 --> 00:48:01,160
So it speeds up the very entropy that broke governance in the first place.

1345
00:48:01,160 --> 00:48:03,560
And that means the next collapse point is inevitable.

1346
00:48:03,560 --> 00:48:06,840
If you don't have an ownership model that survives turnover,

1347
00:48:06,840 --> 00:48:08,880
copilot readiness doesn't exist.

1348
00:48:08,880 --> 00:48:11,200
It's just your tenant moving faster.

1349
00:48:11,200 --> 00:48:15,240
Copilot and agent governance, who controls what it sees and who builds.

1350
00:48:15,240 --> 00:48:19,400
Once copilot is in the tenant, the next governance illusion shows up fast.

1351
00:48:19,400 --> 00:48:22,000
People assume copilot governance is a single toggle.

1352
00:48:22,000 --> 00:48:23,880
It isn't copilot is not one thing.

1353
00:48:23,880 --> 00:48:25,800
It's a delivery mechanism for many things.

1354
00:48:25,800 --> 00:48:29,680
Chat experiences, grounded retrieval, plugins, connectors, and now agents.

1355
00:48:29,680 --> 00:48:32,360
And agents are where governance stops being a content problem

1356
00:48:32,360 --> 00:48:34,040
and becomes an identity problem.

1357
00:48:34,040 --> 00:48:35,880
Because an agent is not a document.

1358
00:48:35,880 --> 00:48:38,280
An agent is a decision-making surface with tools.

1359
00:48:38,280 --> 00:48:42,680
And the thing most people miss is that agent sprawl is going to look exactly like team sprawl,

1360
00:48:42,680 --> 00:48:45,640
except it will be harder to see and faster to multiply.

1361
00:48:45,640 --> 00:48:49,720
If team sprawl creates abandoned containers, agent sprawl creates abandoned actors.

1362
00:48:49,720 --> 00:48:53,480
So the control questions you need to answer are not philosophical, they're mechanical.

1363
00:48:53,480 --> 00:48:54,920
Who controls datascope?

1364
00:48:54,920 --> 00:48:56,240
Who controls toolscope?

1365
00:48:56,240 --> 00:48:57,800
Who controls builder scope?

1366
00:48:57,800 --> 00:48:59,600
And who controls publishing scope?

1367
00:48:59,600 --> 00:49:00,680
Start with datascope.

1368
00:49:00,680 --> 00:49:01,960
What can the agent see?

1369
00:49:01,960 --> 00:49:06,440
In Microsoft 365 terms, an agent is grounded in whatever its configuration points to,

1370
00:49:06,440 --> 00:49:09,360
plus whatever the invoking user already has access to,

1371
00:49:09,360 --> 00:49:12,840
plus whatever the underlying tool calls can retrieve.

1372
00:49:12,840 --> 00:49:16,320
That means you don't have an agent and you have a compound permission story.

1373
00:49:16,320 --> 00:49:18,800
The agent can be configured with SharePoint content,

1374
00:49:18,800 --> 00:49:20,440
sites, or other knowledge sources.

1375
00:49:20,440 --> 00:49:21,800
It can connect to systems.

1376
00:49:21,800 --> 00:49:23,800
And the agent output will reflect that reach.

1377
00:49:23,800 --> 00:49:28,520
So you need to treat knowledge sources like access grants, not like content attachments.

1378
00:49:28,520 --> 00:49:33,160
And if you can't inventory which agents are connected to which repositories you've already lost,

1379
00:49:33,160 --> 00:49:35,640
because what does the agent know becomes?

1380
00:49:35,640 --> 00:49:38,920
Whatever it could reach, when someone configured it three months ago.

1381
00:49:38,920 --> 00:49:41,120
Now, toolscope, what can the agent do?

1382
00:49:41,120 --> 00:49:45,400
This is where most organizations will get burned because they'll fixate on retrieval and ignore action.

1383
00:49:45,400 --> 00:49:47,880
But the agent that can only read is a search assistant.

1384
00:49:47,880 --> 00:49:50,440
The agent that can act is an automation front end.

1385
00:49:50,440 --> 00:49:53,000
So the real boundary is not can it answer questions?

1386
00:49:53,000 --> 00:49:58,920
It's can it trigger workflows, call APIs, send email, move files, create tickets, and change state?

1387
00:49:58,920 --> 00:50:03,000
And once you allow action, you need to decide whether the agent acts as the user,

1388
00:50:03,000 --> 00:50:05,240
as the maker, or as a service identity.

1389
00:50:05,240 --> 00:50:06,800
That's not a minor implementation detail.

1390
00:50:06,800 --> 00:50:08,120
That's the security model.

1391
00:50:08,120 --> 00:50:11,720
If the agent executes with the author's credentials, you've created a privilege proxy.

1392
00:50:11,720 --> 00:50:15,240
Users can trigger actions that run under someone else's authority.

1393
00:50:15,240 --> 00:50:18,520
If it executes as the invoking user, you get a more deterministic model,

1394
00:50:18,520 --> 00:50:21,160
but you also inherit the user's permission chaos.

1395
00:50:21,160 --> 00:50:24,040
If it executes as a service identity, you gain control,

1396
00:50:24,040 --> 00:50:27,240
but only if you govern that identity like a privileged workload.

1397
00:50:27,240 --> 00:50:28,760
These pathways accumulate.

1398
00:50:28,760 --> 00:50:31,160
Now, builder scope.

1399
00:50:31,160 --> 00:50:33,080
Who can build agents?

1400
00:50:33,080 --> 00:50:37,080
This is where the tenant decays quietly, because most organizations won't stop it.

1401
00:50:37,080 --> 00:50:39,040
They can't. The business wants innovation.

1402
00:50:39,040 --> 00:50:40,440
Microsoft makes it easy.

1403
00:50:40,440 --> 00:50:44,440
And blocking creators just drives people to third party AI, which is worse.

1404
00:50:44,440 --> 00:50:47,040
So the governance goal is not prevent building.

1405
00:50:47,040 --> 00:50:48,720
It's make building governable.

1406
00:50:48,720 --> 00:50:51,520
That means builders are identities with entitlements.

1407
00:50:51,520 --> 00:50:55,840
You don't give everyone the ability to publish agents with access to sensitive repositories

1408
00:50:55,840 --> 00:50:56,960
and powerful connectors.

1409
00:50:56,960 --> 00:51:00,560
You scope who can build where they can build which tools they can use

1410
00:51:00,560 --> 00:51:04,800
and what promotion path exists from experimentation to production.

1411
00:51:04,800 --> 00:51:06,920
If you don't do this, you get shadow AI.

1412
00:51:06,920 --> 00:51:10,080
Agents built in the wrong place with the wrong sources using credentials

1413
00:51:10,080 --> 00:51:13,400
nobody reviewed and shared informally because it's useful.

1414
00:51:13,400 --> 00:51:14,560
Then publishing scope.

1415
00:51:14,560 --> 00:51:16,400
Who can deploy agents and to whom?

1416
00:51:16,400 --> 00:51:17,600
This is the enterprise trap.

1417
00:51:17,600 --> 00:51:19,440
A useful agent spreads socially.

1418
00:51:19,440 --> 00:51:20,640
Someone shares it with a team.

1419
00:51:20,640 --> 00:51:21,600
Then another team.

1420
00:51:21,600 --> 00:51:23,600
Then it becomes the way we do it.

1421
00:51:23,600 --> 00:51:27,240
And suddenly the agent's audience boundary is far larger than the risk boundary

1422
00:51:27,240 --> 00:51:28,480
you assumed at creation.

1423
00:51:28,480 --> 00:51:31,920
So publishing has to be treated like app deployment, not like link sharing.

1424
00:51:31,920 --> 00:51:33,080
There has to be inventory.

1425
00:51:33,080 --> 00:51:34,160
There has to be ownership.

1426
00:51:34,160 --> 00:51:35,440
There has to be life cycle.

1427
00:51:35,440 --> 00:51:36,840
There has to be review cadence.

1428
00:51:36,840 --> 00:51:38,440
Treat agents like identities.

1429
00:51:38,440 --> 00:51:39,680
Give them owners.

1430
00:51:39,680 --> 00:51:40,880
Give them environments.

1431
00:51:40,880 --> 00:51:41,880
Give them exploration.

1432
00:51:41,880 --> 00:51:43,520
Give them an attestation rhythm.

1433
00:51:43,520 --> 00:51:46,160
And when an agent has no owner, you don't keep it just in case.

1434
00:51:46,160 --> 00:51:47,160
You got your saw.

1435
00:51:47,160 --> 00:51:49,920
You quarantined it, you reassigned it, or you killed it.

1436
00:51:49,920 --> 00:51:51,920
Now the shortcut, nobody teaches.

1437
00:51:51,920 --> 00:51:54,400
You can't govern agents after they proliferate.

1438
00:51:54,400 --> 00:51:56,280
You can only govern their creation pathways.

1439
00:51:56,280 --> 00:51:58,560
If you remember nothing else, remember this.

1440
00:51:58,560 --> 00:52:00,640
Agents are a control plane expansion.

1441
00:52:00,640 --> 00:52:04,040
They widen the set of things that can be asked, found and done.

1442
00:52:04,040 --> 00:52:08,480
If you let them sprawl the way you let teams sprawl, you won't just have messy collaboration.

1443
00:52:08,480 --> 00:52:10,560
You'll have unaccountable execution.

1444
00:52:10,560 --> 00:52:14,000
And that's the moment where co-pilot governance stops being a feature discussion.

1445
00:52:14,000 --> 00:52:16,880
It becomes the question that ends careers in audit meetings.

1446
00:52:16,880 --> 00:52:19,640
Who approved this thing to act in your tenant?

1447
00:52:19,640 --> 00:52:21,360
And where is that approval enforced today?

1448
00:52:21,360 --> 00:52:25,720
Well, identity governance, entra as control plane, not governance solution.

1449
00:52:25,720 --> 00:52:29,560
So the organization finally gets serious and says, fine, we'll do identity governance.

1450
00:52:29,560 --> 00:52:31,480
Good, that's the correct instinct.

1451
00:52:31,480 --> 00:52:33,320
And then the next illusion shows up.

1452
00:52:33,320 --> 00:52:36,400
The belief that entra is the governance solution for the tenant.

1453
00:52:36,400 --> 00:52:39,760
It isn't entra is the control plane for identity decisions.

1454
00:52:39,760 --> 00:52:43,000
It is not the control plane for tenant life cycle hygiene.

1455
00:52:43,000 --> 00:52:46,960
That distinction matters because most of the mess you're trying to fix isn't who can sign

1456
00:52:46,960 --> 00:52:47,960
in.

1457
00:52:47,960 --> 00:52:50,480
It's what persists when nobody is responsible.

1458
00:52:50,480 --> 00:52:52,920
Entra's job is to answer one question over and over.

1459
00:52:52,920 --> 00:52:57,080
Should this identity be allowed to authenticate and receive tokens for this resource under

1460
00:52:57,080 --> 00:52:58,080
these conditions?

1461
00:52:58,080 --> 00:52:59,720
That's access gating.

1462
00:52:59,720 --> 00:53:01,760
Tenant governance is something else.

1463
00:53:01,760 --> 00:53:06,080
Continuous, cross workload enforcement of ownership, life cycle and risk boundaries across

1464
00:53:06,080 --> 00:53:10,280
teams, SharePoint, OneDrive, Power Platform, and now agents.

1465
00:53:10,280 --> 00:53:14,120
So yes, identity governance is critical, but it will not rescue you from sprawl.

1466
00:53:14,120 --> 00:53:15,960
It will not clean up your dead work spaces.

1467
00:53:15,960 --> 00:53:17,800
It will not unwind broken inheritance.

1468
00:53:17,800 --> 00:53:21,640
And it will not stop automation from using legitimate tokens to move data out of your

1469
00:53:21,640 --> 00:53:22,640
boundaries.

1470
00:53:22,640 --> 00:53:26,680
Now, conditional access is where people usually anchor their hope because it's one of the

1471
00:53:26,680 --> 00:53:29,440
few places where the platform actually says no.

1472
00:53:29,440 --> 00:53:31,680
But conditional access is not a governance loop.

1473
00:53:31,680 --> 00:53:32,840
It is a gate at the edge.

1474
00:53:32,840 --> 00:53:36,040
It's a policy evaluation that sign in and token issuance time.

1475
00:53:36,040 --> 00:53:39,200
It does not recheck whether the user still needs access next week.

1476
00:53:39,200 --> 00:53:42,040
It does not inspect whether the group therein is stale.

1477
00:53:42,040 --> 00:53:44,000
It does not remove the guest you forgot about.

1478
00:53:44,000 --> 00:53:45,480
It does not expire a team.

1479
00:53:45,480 --> 00:53:47,200
It does not reassign an owner.

1480
00:53:47,200 --> 00:53:50,120
It does not review whether your app registration still needs mail.

1481
00:53:50,120 --> 00:53:52,520
Readride.conditional access can reduce exposure.

1482
00:53:52,520 --> 00:53:53,920
It cannot maintain intent.

1483
00:53:53,920 --> 00:53:57,920
And then there's app registrations and service principles, which is where identity governance

1484
00:53:57,920 --> 00:54:01,640
becomes a mirror of the same decay patterns you've already seen elsewhere.

1485
00:54:01,640 --> 00:54:04,120
And app registration starts as a project artifact.

1486
00:54:04,120 --> 00:54:10,080
It exists for a reason, automation, integration, reporting, CI/CD, just make graph calls.

1487
00:54:10,080 --> 00:54:11,080
Fine.

1488
00:54:11,080 --> 00:54:12,560
Then it accumulates permissions.

1489
00:54:12,560 --> 00:54:13,800
Then the project ends.

1490
00:54:13,800 --> 00:54:15,240
Then the service principle stays.

1491
00:54:15,240 --> 00:54:17,200
And nobody remembers why it has what it has.

1492
00:54:17,200 --> 00:54:19,760
This is the identity version of ownerless resources.

1493
00:54:19,760 --> 00:54:21,600
It's the same story just wearing a different badge.

1494
00:54:21,600 --> 00:54:25,440
The tenant fills with service principles that have broad delegated permissions or application

1495
00:54:25,440 --> 00:54:29,240
permissions or certificates that never expire because we'll rotate them later.

1496
00:54:29,240 --> 00:54:31,040
Later like everything else becomes never.

1497
00:54:31,040 --> 00:54:33,960
And once those artifacts exist, they become entropic by design.

1498
00:54:33,960 --> 00:54:35,120
They do not self-ordid.

1499
00:54:35,120 --> 00:54:36,800
They do not self-reduce privilege.

1500
00:54:36,800 --> 00:54:40,000
They do not self-delete when the employee who created them leaves.

1501
00:54:40,000 --> 00:54:41,800
The system preserves state.

1502
00:54:41,800 --> 00:54:46,040
So identity governance has a clear objective that most organizations don't actually implement

1503
00:54:46,040 --> 00:54:49,440
make identity artifacts reviewable and expirable.

1504
00:54:49,440 --> 00:54:51,160
Not reviewed once.

1505
00:54:51,160 --> 00:54:52,160
Reviewable continuously.

1506
00:54:52,160 --> 00:54:55,800
That means app registrations need owners you can root escalation to.

1507
00:54:55,800 --> 00:54:57,120
Service principles need life cycle.

1508
00:54:57,120 --> 00:54:59,560
Privileged roles need time bound activation.

1509
00:54:59,560 --> 00:55:01,360
Access packages need policies that end.

1510
00:55:01,360 --> 00:55:04,440
Most identities need expiration and revalidation.

1511
00:55:04,440 --> 00:55:08,360
Workload identities need the same governance posture as human identities because they are

1512
00:55:08,360 --> 00:55:10,240
the ones doing the quiet work.

1513
00:55:10,240 --> 00:55:12,000
And yes, Entra gives you tools.

1514
00:55:12,000 --> 00:55:15,600
Access reviews, entitlement management, PIM, life cycle workflows.

1515
00:55:15,600 --> 00:55:17,800
Those are real control primitives, but here is the catch.

1516
00:55:17,800 --> 00:55:19,160
They are identity primitives.

1517
00:55:19,160 --> 00:55:23,280
They do not automatically map to the messy resource world unless you design that mapping.

1518
00:55:23,280 --> 00:55:27,560
A SharePoint site can exist with no meaningful owner even if the user life cycle is perfect.

1519
00:55:27,560 --> 00:55:30,680
A team can exist long after all the members moved on.

1520
00:55:30,680 --> 00:55:32,680
And if offboarding is flawless.

1521
00:55:32,680 --> 00:55:36,320
A flow can keep running under a shared connection even if the maker is gone.

1522
00:55:36,320 --> 00:55:41,080
So if you treat Entra governance as the governance solution, you'll build a deterministic identity

1523
00:55:41,080 --> 00:55:43,880
model attached to a probabilistic resources state.

1524
00:55:43,880 --> 00:55:48,040
And you will still fail audits because auditors don't ask, did you have MFA?

1525
00:55:48,040 --> 00:55:50,320
They ask, who approved access to this resource?

1526
00:55:50,320 --> 00:55:52,480
And why do they still have it?

1527
00:55:52,480 --> 00:55:54,800
Identity governance can help answer the who?

1528
00:55:54,800 --> 00:55:59,040
But it often can't answer the resource because the resource governance layer is fragmented.

1529
00:55:59,040 --> 00:56:03,040
So Entra should be treated as what it is, the identity decision engine.

1530
00:56:03,040 --> 00:56:07,520
And then you build above it a unified governance layer that can take identity signals, owner,

1531
00:56:07,520 --> 00:56:11,960
manager, department, termination, role changes and translate them into enforcement across

1532
00:56:11,960 --> 00:56:13,120
the work plane.

1533
00:56:13,120 --> 00:56:14,120
That's the pattern.

1534
00:56:14,120 --> 00:56:17,800
Identity provides authoritative signals, but governance needs to consume those signals and

1535
00:56:17,800 --> 00:56:22,360
drive consequences in teams, SharePoint, OneDrive, Power Platform and agents.

1536
00:56:22,360 --> 00:56:25,920
Otherwise you've built a perfect gate in front of a building where nobody knows what

1537
00:56:25,920 --> 00:56:27,280
rooms exist anymore.

1538
00:56:27,280 --> 00:56:31,080
And now we get to the biggest entropy generator at scale, the Power Platform.

1539
00:56:31,080 --> 00:56:35,040
Because one citizen development hits enterprise volume, governance stops being a security

1540
00:56:35,040 --> 00:56:36,120
controls discussion.

1541
00:56:36,120 --> 00:56:38,640
It becomes an architecture survival problem.

1542
00:56:38,640 --> 00:56:42,240
Erosion case five, onalist resources, the silent killer.

1543
00:56:42,240 --> 00:56:46,400
Onalist resources are the point where every other governance idea collapses, not because

1544
00:56:46,400 --> 00:56:49,760
the controls don't exist because the control loop has no endpoint.

1545
00:56:49,760 --> 00:56:54,760
Every policy, every review, every life cycle process, every please validate this access mechanism,

1546
00:56:54,760 --> 00:56:59,240
assumes there is a human who can answer for the resource, someone who understands why it

1547
00:56:59,240 --> 00:57:02,600
exists, who it serves and what breaks if you touch it.

1548
00:57:02,600 --> 00:57:06,960
When that person doesn't exist, governance becomes guesswork with admin privileges.

1549
00:57:06,960 --> 00:57:08,600
And guesswork is not a control model.

1550
00:57:08,600 --> 00:57:10,280
Onalist teams are the obvious ones.

1551
00:57:10,280 --> 00:57:14,200
The original owners leave, the team keeps running and now nobody has the authority or the

1552
00:57:14,200 --> 00:57:15,840
context to clean it up.

1553
00:57:15,840 --> 00:57:19,200
Memberships stay stale, guests stay invited, channels stay messy.

1554
00:57:19,200 --> 00:57:22,280
The associated SharePoint side continues to store content.

1555
00:57:22,280 --> 00:57:26,440
Members still have access even if they never use it, the resource is alive.

1556
00:57:26,440 --> 00:57:27,960
Accountability is dead.

1557
00:57:27,960 --> 00:57:30,600
Onalist sites are worse because the site is the data plane.

1558
00:57:30,600 --> 00:57:34,840
It's where files live, where inheritance breaks, where links accumulate, where retention

1559
00:57:34,840 --> 00:57:37,560
policies pretend to be a life cycle strategy.

1560
00:57:37,560 --> 00:57:42,080
When nobody owns the site, nobody certifies whether the sharing model is still valid.

1561
00:57:42,080 --> 00:57:45,400
Nobody knows whether that folder shared to someone external was still needed.

1562
00:57:45,400 --> 00:57:48,880
Nobody knows if the company wide links were intentional or just laziness.

1563
00:57:48,880 --> 00:57:51,840
So those permissions persist, not because anyone chose them.

1564
00:57:51,840 --> 00:57:54,280
Nobody removed them.

1565
00:57:54,280 --> 00:57:57,960
Onalist flows are the most dangerous version of this pattern because they don't just expose

1566
00:57:57,960 --> 00:57:59,440
data, they move it.

1567
00:57:59,440 --> 00:58:01,800
A flow can run for months after the maker leaves.

1568
00:58:01,800 --> 00:58:06,000
It can keep using existing connections, it can keep exporting data, it can keep emailing

1569
00:58:06,000 --> 00:58:09,960
attachments and when it fails, it fails like any other automation.

1570
00:58:09,960 --> 00:58:14,760
Quietly or noisily, but without telling you why it existed in the first place.

1571
00:58:14,760 --> 00:58:18,280
It's operational software without an owner, that is pure entropy.

1572
00:58:18,280 --> 00:58:20,120
Onalist apps are the same story with the UI.

1573
00:58:20,120 --> 00:58:23,680
They often sit in the default environment, they collect data, they write to dataverse

1574
00:58:23,680 --> 00:58:27,480
or sharepoint lists, they embed flows, they get shared in team's chats, then the builder

1575
00:58:27,480 --> 00:58:31,560
moves on, the app stays, the data stays and suddenly the audit question isn't, is this

1576
00:58:31,560 --> 00:58:32,560
secure?

1577
00:58:32,560 --> 00:58:34,360
It's us, it's who approved this system.

1578
00:58:34,360 --> 00:58:35,520
And you don't have an answer.

1579
00:58:35,520 --> 00:58:39,680
Now people will try to solve this with reporting, they'll generate a list, they'll open a ticket,

1580
00:58:39,680 --> 00:58:44,320
they'll assign it to an admin, they'll ask IT to become the owner just to fix it.

1581
00:58:44,320 --> 00:58:48,820
That is the moment governance turns into security debt because making IT the owner is not

1582
00:58:48,820 --> 00:58:52,140
ownership, it's custodian ship without context.

1583
00:58:52,140 --> 00:58:56,100
It can hold the keys but I doesn't know what doors should exist, so the remediation becomes

1584
00:58:56,100 --> 00:59:00,700
one of three bad outcomes, ignore it, delete it and break something or keep it and pretend

1585
00:59:00,700 --> 00:59:01,700
it's controlled.

1586
00:59:01,700 --> 00:59:04,220
This is why onalist resources are the silent killer.

1587
00:59:04,220 --> 00:59:08,520
They don't throw obvious errors, they don't always create visible incidents, they just accumulate

1588
00:59:08,520 --> 00:59:13,940
risk until a discovery event happens, and audit a breach, a copilot prompt, a merger,

1589
00:59:13,940 --> 00:59:19,440
a lawsuit, a data subject request, a privileged access review that asks a simple question, nobody

1590
00:59:19,440 --> 00:59:20,440
can answer.

1591
00:59:20,440 --> 00:59:21,440
Why is this still here?

1592
00:59:21,440 --> 00:59:23,100
Now why do onalist resources happen?

1593
00:59:23,100 --> 00:59:27,500
Not because people are lazy, because the tenant is designed to let resources out live humans,

1594
00:59:27,500 --> 00:59:32,220
turnovers normal, projects end, reogs happen, M&A happens, contractors leave, accounts get

1595
00:59:32,220 --> 00:59:37,180
disabled, distribution lists change, people move teams, and in all of that churn, the platform

1596
00:59:37,180 --> 00:59:40,820
will happily preserve the artifacts that were created at peak enthusiasm.

1597
00:59:40,820 --> 00:59:42,620
It will not preserve the intent.

1598
00:59:42,620 --> 00:59:46,880
And that distinction is fatal, intent is not stored in teams metadata, intent is not stored

1599
00:59:46,880 --> 00:59:51,700
in SharePoint permissions, intent is not stored in flows, the only thing that approximates intent

1600
00:59:51,700 --> 00:59:56,740
is ownership, because ownership is the rootable link to context, remove that link and the system

1601
00:59:56,740 --> 00:59:58,620
becomes ungovernable by definition.

1602
00:59:58,620 --> 01:00:02,940
So here's the core claim stated plainly, without ownership governance is impossible, not

1603
01:00:02,940 --> 01:00:07,460
hard impossible, because governance is not visibility, governance is decision making

1604
01:00:07,460 --> 01:00:11,180
with consequence, and decision making requires accountability.

1605
01:00:11,180 --> 01:00:14,940
This is why the control plain pattern later in this video starts with ownership enforcement,

1606
01:00:14,940 --> 01:00:19,780
not policy tuning, you can't deal P your way out of a tenant full of orphan systems, you

1607
01:00:19,780 --> 01:00:23,740
can't label your way out, you can't conditional access your way out, those are controls that

1608
01:00:23,740 --> 01:00:28,500
assume a stable resource life cycle, onalist resources are the absence of life cycle.

1609
01:00:28,500 --> 01:00:32,340
So the correct first move is not another policy, it's to make ownership a primitive you enforce

1610
01:00:32,340 --> 01:00:38,460
everywhere, minimum owners, no owner remediation, escalation paths and expiration when accountability

1611
01:00:38,460 --> 01:00:42,220
cannot be restored, because if you don't do that, every other governance investment becomes

1612
01:00:42,220 --> 01:00:47,620
theater again, and the tenant stays beyond control, power platform governance reality,

1613
01:00:47,620 --> 01:00:51,860
citizen development at enterprise scale, power platform governance is where good intentions

1614
01:00:51,860 --> 01:00:56,140
go to be operationalized into chaos, not because citizen developers are reckless, because

1615
01:00:56,140 --> 01:01:00,340
the platform is structurally designed to let small solutions become enterprise dependencies

1616
01:01:00,340 --> 01:01:03,340
without ever passing through an enterprise control point.

1617
01:01:03,340 --> 01:01:07,660
This is the core mismatch, IT thinks in systems, makers think in outcomes, the platform rewards

1618
01:01:07,660 --> 01:01:12,860
outcomes, so the estate grows in the only direction it can outward, start with environments, because

1619
01:01:12,860 --> 01:01:16,420
environments are the only boundary primitive the power platform gives you that resembles

1620
01:01:16,420 --> 01:01:22,060
a tenancy within the tenancy, and most organizations ignore them until it hurts, the default environment

1621
01:01:22,060 --> 01:01:27,060
is the governance sinkhole, it exists, it's always there, it's easy, everyone can build

1622
01:01:27,060 --> 01:01:31,580
in it unless you explicitly stop them, so everything ends up there, prototypes, personal

1623
01:01:31,580 --> 01:01:36,460
automations, departmental apps, temporary solutions that quietly become permanent, and experiments

1624
01:01:36,460 --> 01:01:42,020
that accidentally touch real data, that distinction matters, because one's business logic lives

1625
01:01:42,020 --> 01:01:47,140
in the default environment, you have no meaningful separation between experimentation and production,

1626
01:01:47,140 --> 01:01:52,540
you have one shared pool of makers, connectors, data sources, and privileges, you've turned

1627
01:01:52,540 --> 01:01:57,620
your tenant into a shared development workstation, and then you act surprised when something breaks,

1628
01:01:57,620 --> 01:02:02,540
next comes connector sprawl, and it's worse than people admit, the uncomfortable truth.

1629
01:02:02,540 --> 01:02:05,540
Sanctioned connector is not the same as safe behavior.

1630
01:02:05,540 --> 01:02:11,500
SharePoint, Outlook, Teams, Dataverse, and HTTP are not benign just because they're Microsoft

1631
01:02:11,500 --> 01:02:16,220
or common, they are data movement interfaces, so the risk is not third party connectors exist,

1632
01:02:16,220 --> 01:02:20,420
and the risk is that connectors allow lateral movement between systems with different governance

1633
01:02:20,420 --> 01:02:21,420
models.

1634
01:02:21,420 --> 01:02:26,460
A power app with a nice UI can call a flow that uses a connector with broad access, users

1635
01:02:26,460 --> 01:02:30,860
interact with the app and believe they're operating inside a control business process,

1636
01:02:30,860 --> 01:02:35,420
in reality the app is a front end to automation with whatever privileges the builder attached.

1637
01:02:35,420 --> 01:02:39,500
Power apps and flows become coupled risk, the UI hides the behavior, that means your threat

1638
01:02:39,500 --> 01:02:42,540
model can't stop at who has access to the app.

1639
01:02:42,540 --> 01:02:47,060
You have to model what does the app execute under which identity and what does it touch,

1640
01:02:47,060 --> 01:02:49,500
and most tenants don't.

1641
01:02:49,500 --> 01:02:53,940
Then there's the default maker culture failure people promote solutions by copying them.

1642
01:02:53,940 --> 01:02:57,940
Copping an app copies its assumptions, copying a flow copies its connectors, copying a solution

1643
01:02:57,940 --> 01:03:01,780
copies its security model, each copy is a new artifact with a life cycle that nobody

1644
01:03:01,780 --> 01:03:05,660
designed, it sprawl with the appearance of agility.

1645
01:03:05,660 --> 01:03:08,980
Now add the bigger spillover, power BI and fabric.

1646
01:03:08,980 --> 01:03:13,660
Most organizations treat reporting as read only, therefore low risk, that's a childish model

1647
01:03:13,660 --> 01:03:15,420
of information flow.

1648
01:03:15,420 --> 01:03:19,300
Reports become distribution channels for data, data sets become shared assets, workspaces

1649
01:03:19,300 --> 01:03:24,300
become pseudo applications, and publishing becomes a visibility event, not a governance event,

1650
01:03:24,300 --> 01:03:27,060
so you get data publishing without life cycle rigor.

1651
01:03:27,060 --> 01:03:29,740
The same ownerless pattern appears here too.

1652
01:03:29,740 --> 01:03:34,580
Workspaces without accountable owners, data sets with unclear stewardship, reports shared

1653
01:03:34,580 --> 01:03:39,140
broadly because people need it, and a long tail of stale content that remains discoverable

1654
01:03:39,140 --> 01:03:42,100
and trusted long after it should have been retired.

1655
01:03:42,100 --> 01:03:46,140
And then copilot shows up and now your analytics layer becomes another retrieval surface,

1656
01:03:46,140 --> 01:03:49,540
so what does governance look like when citizen development hits enterprise scale?

1657
01:03:49,540 --> 01:03:52,660
It looks like an environment strategy first, not an app strategy.

1658
01:03:52,660 --> 01:03:56,900
You need explicit tiers, personal development, departmental development, control test and

1659
01:03:56,900 --> 01:03:57,900
production.

1660
01:03:57,900 --> 01:04:03,060
Control promotion paths, so I built a thing does not automatically become the business depends

1661
01:04:03,060 --> 01:04:04,060
on this.

1662
01:04:04,060 --> 01:04:07,980
You need maker boundaries, who can build where, who can use which connectors and which data

1663
01:04:07,980 --> 01:04:10,020
sources are allowed in which environments.

1664
01:04:10,020 --> 01:04:13,740
That's not bureaucracy, that's the only way to keep a low-coder state from turning into

1665
01:04:13,740 --> 01:04:16,060
an unbounded integration fabric.

1666
01:04:16,060 --> 01:04:19,700
And you need least privileged execution, stop letting apps and flows run under ambiguous

1667
01:04:19,700 --> 01:04:21,740
connections and shared credentials.

1668
01:04:21,740 --> 01:04:26,100
If you can't explain deterministically whose authority is being exercised, you've already

1669
01:04:26,100 --> 01:04:29,020
lost control, finally you need controlled promotion.

1670
01:04:29,020 --> 01:04:33,220
Not sent me the link, solutions moved through environments, changes are reviewed, ownership

1671
01:04:33,220 --> 01:04:36,020
is explicit, and retirement is enforced.

1672
01:04:36,020 --> 01:04:40,180
Because the core law of power platform is the same law as the rest of Microsoft 365, if

1673
01:04:40,180 --> 01:04:44,260
you don't enforce life cycle, the system will preserve everything forever.

1674
01:04:44,260 --> 01:04:48,380
Citizen development at enterprise scale isn't a threat to governance, it is governance.

1675
01:04:48,380 --> 01:04:51,540
Because the moment your business can build systems, your governance model has to treat

1676
01:04:51,540 --> 01:04:54,300
builders like engineers and apps like software.

1677
01:04:54,300 --> 01:04:57,700
Otherwise you're not running a platform, you're running a hobby store with tenant-wide

1678
01:04:57,700 --> 01:04:58,900
permissions.

1679
01:04:58,900 --> 01:05:02,060
The silo tax, why native governance can't converge.

1680
01:05:02,060 --> 01:05:05,700
Now the part nobody wants to admit out loud, even if you do all the right things in each

1681
01:05:05,700 --> 01:05:09,660
workload, native governance still can't converge into a single control model.

1682
01:05:09,660 --> 01:05:13,300
Not because the admins are lazy, because the tenant isn't governed by one system, it's

1683
01:05:13,300 --> 01:05:17,460
governed by a set of product silos with different policy primitives, different telemetry and

1684
01:05:17,460 --> 01:05:21,020
different life cycle semantics, that's the silo tax.

1685
01:05:21,020 --> 01:05:24,140
Every time you try to answer a simple question, you pay it.

1686
01:05:24,140 --> 01:05:25,620
What resources do we have?

1687
01:05:25,620 --> 01:05:27,140
Who owns them?

1688
01:05:27,140 --> 01:05:28,900
Who has access?

1689
01:05:28,900 --> 01:05:30,620
What changed this week?

1690
01:05:30,620 --> 01:05:32,300
What is risky right now?

1691
01:05:32,300 --> 01:05:36,380
Native tooling answers each of those questions partially, depending on which admin center

1692
01:05:36,380 --> 01:05:37,380
you're standing in.

1693
01:05:37,380 --> 01:05:40,420
And the moment you need the cross-service answer, you become the integration layer.

1694
01:05:40,420 --> 01:05:44,500
You export from here, you correlate in Excel, you write a script, you build a Power BI report,

1695
01:05:44,500 --> 01:05:49,460
you create a runbook, you hope it keeps working after Microsoft changes in API or UI label,

1696
01:05:49,460 --> 01:05:51,980
that's not governance, that's human middleware.

1697
01:05:51,980 --> 01:05:55,180
And centers reflect product or boundaries, not tenant reality.

1698
01:05:55,180 --> 01:05:59,060
Teams has its world, SharePoint has its world, Power Platform has its world, Entra has its

1699
01:05:59,060 --> 01:06:02,740
world, Perview has its world, Copilot now has its world, your tenant doesn't live in those

1700
01:06:02,740 --> 01:06:06,980
worlds, your tenant lives in the collisions between them, a team provisions a SharePoint site,

1701
01:06:06,980 --> 01:06:11,980
a plan a plan, a mailbox, a set of permissions, then a user shares a file with an anyone link,

1702
01:06:11,980 --> 01:06:16,060
then a flow picks it up and emails it, then Copilot summarizes it, then an agent uses

1703
01:06:16,060 --> 01:06:20,580
it as grounding, then an auditor asks who approved it, which admin center owns that incident,

1704
01:06:20,580 --> 01:06:21,580
none of them.

1705
01:06:21,580 --> 01:06:26,340
Distinction matters, because governance fails specifically in the seams, where an action

1706
01:06:26,340 --> 01:06:30,780
in one workload becomes exposure in another and no single native tool can represent that

1707
01:06:30,780 --> 01:06:35,980
chain as a single risk object, telemetry fragmentation is the next tax you pay, each workload

1708
01:06:35,980 --> 01:06:41,300
can show you what it thinks matters, Teams can show membership and some settings, SharePoint

1709
01:06:41,300 --> 01:06:46,660
can show sharing and permissions, but not in a way that naturally maps to workspace risk.

1710
01:06:46,660 --> 01:06:51,740
Our platform can show flows, but not always in a way that maps to data sensitivity, entra

1711
01:06:51,740 --> 01:06:55,740
can show sign-ins and role activations, but it can't tell you whether the site being accessed

1712
01:06:55,740 --> 01:07:00,940
is onerless and overshared, so you can have visibility everywhere and still have no decision.

1713
01:07:00,940 --> 01:07:04,420
That's governance theatre at scale, dashboards without consequence.

1714
01:07:04,420 --> 01:07:08,820
Policy fragmentation is even worse, controls do not behave consistently across services,

1715
01:07:08,820 --> 01:07:13,140
a label means something different depending on whether you're in Perview, SharePoint, Teams,

1716
01:07:13,140 --> 01:07:14,540
or Office apps.

1717
01:07:14,540 --> 01:07:19,100
Social access means guests and Teams, sharing links and SharePoint, external identities and

1718
01:07:19,100 --> 01:07:23,900
entra, connectors in power platform and web grounding in co-pilot, and each of those has a different

1719
01:07:23,900 --> 01:07:28,820
enforcement mechanism, some settings block, some settings warn, some settings require licensing,

1720
01:07:28,820 --> 01:07:30,980
some settings apply only to new objects.

1721
01:07:30,980 --> 01:07:35,060
Some settings apply only if the user uses the modern experience, some settings exist,

1722
01:07:35,060 --> 01:07:39,300
but the user can override them with the justification that nobody reads, so you end up with

1723
01:07:39,300 --> 01:07:43,500
inconsistent enforcement primitives across the tenant that creates a predictable result,

1724
01:07:43,500 --> 01:07:44,900
but the policy drift.

1725
01:07:44,900 --> 01:07:48,980
Not because people change the policy, because the policy doesn't mean the same thing everywhere

1726
01:07:48,980 --> 01:07:53,780
and new workloads keep introducing new pathways, life cycle fragmentation is the final bill,

1727
01:07:53,780 --> 01:07:55,820
creation exists everywhere.

1728
01:07:55,820 --> 01:08:00,140
Retirement exists almost nowhere, Teams can be created through multiple surfaces, groups

1729
01:08:00,140 --> 01:08:04,420
can be created from Outlook, sites can be created from SharePoint, flows can be created

1730
01:08:04,420 --> 01:08:08,780
from templates, agents can be created from multiple builders, content can be shared from

1731
01:08:08,780 --> 01:08:12,620
one drive with one click, but when does the system force an end, when does it automatically

1732
01:08:12,620 --> 01:08:16,460
degrade access, when does it root on own resources to remediation?

1733
01:08:16,460 --> 01:08:19,540
When does it prove that a workspace still has a justified business purpose?

1734
01:08:19,540 --> 01:08:23,740
It doesn't, so governance becomes periodic review work, and periodic review work becomes

1735
01:08:23,740 --> 01:08:28,060
fatigue and fatigue becomes rubber stamping and rubber stamping becomes entropy, the tenant

1736
01:08:28,060 --> 01:08:32,620
keeps expanding, your control model keeps eroding, and when you finally get a consolidated

1737
01:08:32,620 --> 01:08:36,420
report it's already stale because the system is dynamic and your governance process is

1738
01:08:36,420 --> 01:08:40,980
batch oriented, this is why native governance can't converge, not because it's bad, because

1739
01:08:40,980 --> 01:08:44,820
it's not a unified control plane, it's a collection of necessary components, each correct in

1740
01:08:44,820 --> 01:08:48,700
isolation, non-sufficient in aggregate, so the result is inevitable, governance becomes

1741
01:08:48,700 --> 01:08:53,020
manual correlation work and manual correlation does not scale, and the only escape is to stop

1742
01:08:53,020 --> 01:08:56,580
trying to govern five silos separately and hoping they add up to control, you need a

1743
01:08:56,580 --> 01:09:01,300
layer that treats the tenant as one system, cross service inventory, consistent ownership,

1744
01:09:01,300 --> 01:09:05,900
life cycle enforcement, and a risk model that understands blast radius across workloads,

1745
01:09:05,900 --> 01:09:10,780
otherwise you're not governing Microsoft 365, you're chasing it, control pattern one,

1746
01:09:10,780 --> 01:09:14,380
ownership is a control plane, so here's the first control pattern that actually survives

1747
01:09:14,380 --> 01:09:19,020
contact with reality ownership as a control plane, not re-arsth teams to nominate an owner,

1748
01:09:19,020 --> 01:09:24,140
not re-hope managers will keep it updated, enforced ownership everywhere as a tenant primitive,

1749
01:09:24,140 --> 01:09:29,220
because ownership is the only governance mechanism that can root decisions back to context, policies

1750
01:09:29,220 --> 01:09:33,260
don't have context, admins don't have context, audit logs don't have context, the only thing

1751
01:09:33,260 --> 01:09:37,900
that reliably points to context is a human who is accountable for the resource, and if

1752
01:09:37,900 --> 01:09:41,500
you don't have that, you don't have governance, you have a crime scene with a spreadsheet,

1753
01:09:41,500 --> 01:09:45,460
so what does ownership as a control plane mean in practice, it means the tenant treats

1754
01:09:45,460 --> 01:09:50,700
no owner as an invalid state, not an unfortunate condition, a team without an owner is not a collaboration

1755
01:09:50,700 --> 01:09:55,140
space, it is an often asset with unknown blast radius, a share point site without an owner

1756
01:09:55,140 --> 01:09:59,860
is not a site, it is an unbounded permission graph with no escalation path, a flow without

1757
01:09:59,860 --> 01:10:04,940
an owner is not automation, it is an unaccountable integration running under ambiguous identity,

1758
01:10:04,940 --> 01:10:09,020
but an agent without an owner is not innovation, it is an actor in your environment that nobody

1759
01:10:09,020 --> 01:10:14,540
can explain, so the first part is enforcement minimum owners and not as guidance, as a rule.

1760
01:10:14,540 --> 01:10:19,580
Two owners is the baseline, because it acknowledges turnover, one owner is a single point of organizational

1761
01:10:19,580 --> 01:10:23,820
failure, and yes, it's fine, it's just a small project is how you end up with a tenant full

1762
01:10:23,820 --> 01:10:26,700
of abandoned small projects that still contain data.

1763
01:10:26,700 --> 01:10:30,620
Once you nail that everything else clicks, ownership becomes the anchor for every review,

1764
01:10:30,620 --> 01:10:34,700
every escalation, every life cycle decision and every remediation workflow.

1765
01:10:34,700 --> 01:10:39,380
The second part is visibility, make ownership visible in a way that creates consequence.

1766
01:10:39,380 --> 01:10:43,020
Most organizations technically have owners in places, they just don't have ownership as

1767
01:10:43,020 --> 01:10:47,100
a governance signal, it's hidden in a UI, it's not monitored, it's not alerted, it's

1768
01:10:47,100 --> 01:10:51,420
not reported in a way that someone is accountable for, so you build an ownership map, which resources

1769
01:10:51,420 --> 01:10:55,740
exist, who owns them and where the ownership is failing, not quarterly, continuously, and

1770
01:10:55,740 --> 01:11:00,220
you don't measure how many resources exist, you measure how many resources are unowned,

1771
01:11:00,220 --> 01:11:02,540
because unowned is the failure state.

1772
01:11:02,540 --> 01:11:07,580
The third part is remediation, no owner remediation can't be a human project, it has to be a system

1773
01:11:07,580 --> 01:11:12,060
behavior, if a resource drops below minimum owners, it triggers a remediation loop with

1774
01:11:12,060 --> 01:11:16,540
a grace period, that grace period exists because humans need time to fix things, but it is

1775
01:11:16,540 --> 01:11:20,820
time-bound and it ends during the grace period, the system notifies the remaining owners,

1776
01:11:20,820 --> 01:11:25,220
the resource members and the manager chain, depending on how your organization is structured,

1777
01:11:25,220 --> 01:11:29,780
if no one responds, you escalate owner to manager, manager to governance team.

1778
01:11:29,780 --> 01:11:34,580
governance team to a defined resolution, reassign archive, restrict or delete, and this is the

1779
01:11:34,580 --> 01:11:39,660
part people avoid because it feels harsh, if accountability cannot be restored, the resource

1780
01:11:39,660 --> 01:11:44,780
must degrade, not because you enjoy breaking things, because unaccountable assets are security

1781
01:11:44,780 --> 01:11:51,100
debt generators, so you degrade access intentionally, you restrict external sharing, you block new guests,

1782
01:11:51,100 --> 01:11:56,180
you disable public links, you move the resource to read only, you quarantine the agent, you pause

1783
01:11:56,180 --> 01:12:02,260
the flow, you stop the thing from continuing to expand its blast radius, while nobody is responsible,

1784
01:12:02,260 --> 01:12:07,940
that's not punishment, that is entropy containment. Now the question everyone asks next is,

1785
01:12:07,940 --> 01:12:13,540
but how do we pick the new owner? You don't guess. You design an escalation path that is

1786
01:12:13,540 --> 01:12:20,020
deterministic, owners, then manager, then functional owner, then governance team, if you can't resolve

1787
01:12:20,020 --> 01:12:23,700
ownership through a defined chain, then you've discovered a deeper organizational problem,

1788
01:12:23,700 --> 01:12:27,940
the business doesn't actually own its own systems, and that is exactly what governance exists

1789
01:12:27,940 --> 01:12:32,020
to expose, here's the result, this patent produces when it's enforced continuously,

1790
01:12:32,020 --> 01:12:36,500
ownerless resources stop being a permanent condition and become a temporary incident,

1791
01:12:36,500 --> 01:12:40,900
and that's the difference between governance and cleanup. Cleanup is a project, ownership

1792
01:12:40,900 --> 01:12:45,060
enforcement is a control plane behavior, so the big takeaway in this section is simple,

1793
01:12:45,060 --> 01:12:49,780
you can't govern what nobody owns, and you can't scale governance if ownership isn't enforced by

1794
01:12:49,780 --> 01:12:55,460
design, and once ownership exists you finally get to do the next thing that native governance almost

1795
01:12:55,460 --> 01:13:01,300
never enables cleanly, you can prioritize by risk instead of drowning in noise. Control pattern 2,

1796
01:13:01,300 --> 01:13:06,020
risk-based prioritization that actually works, ownership gives you accountability,

1797
01:13:06,020 --> 01:13:10,260
risk-based prioritization gives you throughput because the next failure mode is predictable,

1798
01:13:10,260 --> 01:13:14,900
once you can finally see everything you drown in it, you build reports, you find hundreds of issues,

1799
01:13:14,900 --> 01:13:19,220
then nothing gets fixed because the team has no way to separate annoying from dangerous,

1800
01:13:19,220 --> 01:13:24,180
this is where most governance programs die, they treat every finding like it matters equally,

1801
01:13:24,180 --> 01:13:29,540
it doesn't, equal severity thinking creates severity inflation and severity inflation creates

1802
01:13:29,540 --> 01:13:33,940
paralysis, when everything is read nobody moves, they either ignore it or they chase whatever

1803
01:13:33,940 --> 01:13:38,980
screams loudest, that's not prioritization, that's governance by irritation, risk-based prioritization

1804
01:13:38,980 --> 01:13:44,500
that works is brutally simple, you rank work by consequence, not by policy violation count,

1805
01:13:44,500 --> 01:13:47,940
the inputs are stable, they don't depend on which admin center you're in,

1806
01:13:47,940 --> 01:13:52,180
they don't depend on which product team name the control, they map to system behavior,

1807
01:13:52,180 --> 01:13:56,820
blast radius, data sensitivity, external exposure, automation pathways, if you can score those

1808
01:13:56,820 --> 01:14:00,740
four inputs consistently you can sort the entire tenant by what will hurt first.

1809
01:14:00,740 --> 01:14:05,780
Blast radius is the audience boundary, a team with five members is not the same risk as a team with

1810
01:14:05,780 --> 01:14:10,900
five thousand, a file shared to one external guest is not the same as a file shared with anyone,

1811
01:14:10,900 --> 01:14:16,100
a flow used by one person is not the same as a flow embedded in a critical process,

1812
01:14:16,100 --> 01:14:20,980
the thing most people miss is that blast radius can be internal too, everyone in the company links

1813
01:14:20,980 --> 01:14:25,860
are internal exposure at enterprise scale, they turn one person's convenience into tenant wide

1814
01:14:25,860 --> 01:14:32,180
availability, data sensitivity is not this side has a confidential label, you already learned labels

1815
01:14:32,180 --> 01:14:37,060
are not access governance, sensitivity is the combination of what the data is and what it enables,

1816
01:14:37,060 --> 01:14:42,660
contracts, HR records, financials, customer data, identity artifacts, API keys, anything that

1817
01:14:42,660 --> 01:14:46,980
materially changes business risk if it escapes, if you don't have a perfect classifier fine,

1818
01:14:46,980 --> 01:14:51,140
you don't need perfect, you need consistent, you need a model that errors on the side of protecting

1819
01:14:51,140 --> 01:14:55,700
high impact content sources and high impact destinations, external exposure is exactly what it

1820
01:14:55,700 --> 01:15:00,020
sounds like, guests, anonymous links and any path where the organization is no longer the only

1821
01:15:00,020 --> 01:15:04,660
security boundary and external now includes AI. If an agent can reach an external system that is

1822
01:15:04,660 --> 01:15:10,180
external exposure, if a flow can pose to a third party SaaS that is external exposure, automation pathways

1823
01:15:10,180 --> 01:15:15,300
are the multiplier, a mispermissioned file is bad, a mispermissioned file that is automatically copied

1824
01:15:15,300 --> 01:15:20,100
to a broader location is worse, a mispermissioned file that is automatically emailed to a distribution

1825
01:15:20,100 --> 01:15:25,140
list is worse, a mispermissioned file that becomes a knowledge source for an agent that answers questions

1826
01:15:25,140 --> 01:15:30,500
at scale is worse, automation turns static risk into moving risk and once risk moves, you lose the

1827
01:15:30,500 --> 01:15:35,460
ability to contain it with periodic review. Now here's the operational difference, risk models

1828
01:15:35,460 --> 01:15:40,820
don't exist to generate prettier dashboards, they exist to drive consequence so you stop measuring

1829
01:15:40,820 --> 01:15:45,620
findings, you measure fixes, you measure time to detection and time to remediation for the few

1830
01:15:45,620 --> 01:15:49,700
categories that actually matter that means you pick a small number of control objectives and

1831
01:15:49,700 --> 01:15:54,580
enforce them aggressively. For example, high-risk power automate flows identified in under seven days,

1832
01:15:54,580 --> 01:15:59,540
not we reviewed flows quarterly, seven days because the system can create a thousand new flows

1833
01:15:59,540 --> 01:16:04,100
between quarterly reviews, the volume will win so you set a detection target that beats the

1834
01:16:04,100 --> 01:16:08,820
platform's rate of entropy and you also separate quick wins from structural wins, quick wins are

1835
01:16:08,820 --> 01:16:14,020
things like onalous remediation, expired links, anonymous links, blocked users lingering in

1836
01:16:14,020 --> 01:16:19,460
membership lists, dead guests, abandoned workspaces. Structural wins are things like environment strategy,

1837
01:16:19,460 --> 01:16:23,700
promotion paths, enforced exploration, governance routing and consistent ownership enforcement

1838
01:16:23,700 --> 01:16:28,660
across workloads. Most organizations invert this, they start with structural redesign because it

1839
01:16:28,660 --> 01:16:33,540
feels strategic but they don't stabilize the current mess. So they spend six months designing a

1840
01:16:33,540 --> 01:16:37,940
future state while the current state keeps decaying and that's a trap. The better method is to kill

1841
01:16:37,940 --> 01:16:42,660
the highest impact risk first then use the recovered operational oxygen to build the structural

1842
01:16:42,660 --> 01:16:47,060
controls that prevent it from returning and you need reporting that drives action. The thing most

1843
01:16:47,060 --> 01:16:51,220
people miss is that reporting is not evidence of control reporting is evidence of observation,

1844
01:16:51,220 --> 01:16:56,740
control requires consequence. So your dashboards don't show how many issues exist. They show what

1845
01:16:56,740 --> 01:17:02,180
was fixed, what wasn't, who owns the backlog and what will be escalated next. If a high-risk asset

1846
01:17:02,180 --> 01:17:08,260
stays unresolved past your threshold, something happens. Access is degraded, sharing is restricted,

1847
01:17:08,260 --> 01:17:13,140
the resource is quarantined or the issue is forced into a decision queue. This is the core shift.

1848
01:17:13,140 --> 01:17:18,260
Findings are not information, findings are work and work that doesn't get routed into consequences

1849
01:17:18,260 --> 01:17:22,980
just another form of theater. Once you have ownership and risk prioritization working together,

1850
01:17:22,980 --> 01:17:27,620
you can finally answer the question everyone's pretending to answer already. Are you actually ready

1851
01:17:27,620 --> 01:17:31,860
for co-pilot? Now you can prove it because you can baseline the riskier surfaces first instead of

1852
01:17:31,860 --> 01:17:37,380
boiling the ocean. Ownership gives you accountability. Risk-based prioritization gives you throughput

1853
01:17:37,380 --> 01:17:42,340
because the next failure mode is predictable. Once you can finally see everything, you drown in it,

1854
01:17:42,340 --> 01:17:46,740
you build reports, you find hundreds of issues, then nothing gets fixed because the team has no

1855
01:17:46,740 --> 01:17:51,540
way to separate annoying from dangerous. This is where most governance programs die. They treat

1856
01:17:51,540 --> 01:17:56,100
every finding like it matters equally. It doesn't equal severity thinking creates severity inflation

1857
01:17:56,100 --> 01:18:00,660
and severity inflation creates paralysis when everything is red nobody moves. They either ignore it

1858
01:18:00,660 --> 01:18:05,860
or they chase whatever screams loudest. That's not prioritization. That's governance by irritation.

1859
01:18:05,860 --> 01:18:10,740
Risk-based prioritization that works is brutally simple. You rank work by consequence, not by

1860
01:18:10,740 --> 01:18:14,900
policy violation count. The inputs are stable. They don't depend on which admin center you're in.

1861
01:18:14,900 --> 01:18:20,020
They don't depend on which product team name the control. They map to system behavior. Blast radius,

1862
01:18:20,020 --> 01:18:25,380
data sensitivity, external exposure, automation pathways. If you can score those four inputs

1863
01:18:25,380 --> 01:18:30,820
consistently, you can sort the entire tenant by what will hurt first. Blast radius is the audience

1864
01:18:30,820 --> 01:18:35,300
boundary. A team with five members is not the same risk as a team with five thousand. A file shared

1865
01:18:35,300 --> 01:18:40,660
to one external guest is not the same as a file shared with anyone. A flow used by one person is not

1866
01:18:40,660 --> 01:18:45,380
the same as a flow embedded in a critical process. The thing most people miss is that blast radius

1867
01:18:45,380 --> 01:18:50,100
can be internal too. Everyone in the company links our internal exposure at enterprise scale. They

1868
01:18:50,100 --> 01:18:54,900
turn one person's convenience into tenant-wide availability. Data sensitivity is not this site has a

1869
01:18:54,900 --> 01:19:00,340
confidential label. You already learnt labels are not access governance. Sensitivity is the combination of

1870
01:19:00,340 --> 01:19:07,140
what the data is and what it enables. Contracts, HR records, financials, customer data, identity artifacts,

1871
01:19:07,140 --> 01:19:12,580
API keys, anything that materially changes business risk if it escapes. If you don't have a perfect

1872
01:19:12,580 --> 01:19:17,460
classifier fine, you don't need perfect, you need consistent, you need a model that airs on the

1873
01:19:17,460 --> 01:19:22,020
side of protecting high impact content sources and high impact destinations. External exposure is

1874
01:19:22,020 --> 01:19:27,780
exactly what it sounds like. Guests, anonymous links, and any path where the organization is no longer

1875
01:19:27,780 --> 01:19:33,300
the only security boundary. And external now includes AI. If an agent can reach an external system

1876
01:19:33,300 --> 01:19:38,260
that is external exposure. If a flow can pose to a third party SaaS that is external exposure,

1877
01:19:38,260 --> 01:19:43,300
automation pathways are the multiplier. A mispermission file is bad, a mispermission file that is

1878
01:19:43,300 --> 01:19:49,300
automatically copied to a broader location is worse. A mispermission file that is automatically emailed

1879
01:19:49,300 --> 01:19:53,860
to a distribution list is worse. A mispermission file that becomes a knowledge source for an agent

1880
01:19:53,860 --> 01:19:58,180
that answers questions at scale is worse. Automation turns static risk into moving risk.

1881
01:19:58,180 --> 01:20:02,660
And once risk moves, you lose the ability to contain it with periodic review. Now here's the

1882
01:20:02,660 --> 01:20:07,540
operational difference. Risk models don't exist to generate prettier dashboards. They exist to drive

1883
01:20:07,540 --> 01:20:12,900
consequence. So you stop measuring findings. You measure fixes, you measure time to detection and

1884
01:20:12,900 --> 01:20:17,300
time to remediation for the few categories that actually matter. That means you pick a small number

1885
01:20:17,300 --> 01:20:23,140
of control objectives and enforce them aggressively. For example, high-risk power automate flows identified

1886
01:20:23,140 --> 01:20:28,660
in under seven days. Not we reviewed flows quarterly, seven days, because the system can create a

1887
01:20:28,660 --> 01:20:33,700
thousand new flows between quarterly reviews. The volume will win, so you set a detection target

1888
01:20:33,700 --> 01:20:38,340
that beats the platform's rate of entropy. You also separate quick wins from structural wins.

1889
01:20:38,340 --> 01:20:42,660
Quick wins are things like, onalous remediation, expired links, anonymous links,

1890
01:20:42,660 --> 01:20:46,740
blocked users lingering in membership lists, dead guests, abandoned workspaces.

1891
01:20:46,740 --> 01:20:51,380
Structural wins are things like environment strategy, promotion paths, enforced expiration,

1892
01:20:51,380 --> 01:20:56,340
governance routing and consistent ownership enforcement across workloads. Most organizations

1893
01:20:56,340 --> 01:21:00,820
invert this. They start with structural redesign because it feels strategic, but they don't

1894
01:21:00,820 --> 01:21:05,380
stabilize the current mess. So they spend six months designing a future state while the current

1895
01:21:05,380 --> 01:21:10,340
state keeps decaying. That's a trap. The better method is to kill the highest impact risk first,

1896
01:21:10,340 --> 01:21:14,900
then use the recovered operational oxygen to build the structural controls that prevent it from

1897
01:21:14,900 --> 01:21:19,540
returning. And you need reporting that drives action. The thing most people miss is that reporting is

1898
01:21:19,540 --> 01:21:24,180
not evidence of control, reporting is evidence of observation, control requires consequence.

1899
01:21:24,180 --> 01:21:29,860
So your dashboards don't show how many issues exist. They show what was fixed, what wasn't,

1900
01:21:29,860 --> 01:21:35,060
who owns the backlog, and what will be escalated next. If a high-risk asset stays unresolved past

1901
01:21:35,060 --> 01:21:40,900
your threshold, something happens. Access is degraded, sharing is restricted, the resource is quarantined,

1902
01:21:40,900 --> 01:21:46,100
or the issue is forced into a decision queue. This is the core shift, findings are not information,

1903
01:21:46,100 --> 01:21:50,740
findings are work, and work that doesn't get routed into consequence is just another form of

1904
01:21:50,740 --> 01:21:55,540
theater. Once you have ownership and risk prioritization working together, you can finally answer

1905
01:21:55,540 --> 01:22:00,020
the question everyone's pretending to answer already. Are you actually ready for co-pilot?

1906
01:22:00,020 --> 01:22:04,340
Now you can prove it because you can baseline the riskiest surface is first instead of boiling the

1907
01:22:04,340 --> 01:22:11,540
ocean. 700 words. I Ready Governance is where most tenants finally admit what they've been calling

1908
01:22:11,540 --> 01:22:16,500
governance was just tolerance. Because co-pilot and agents don't give you time, they don't wait for

1909
01:22:16,500 --> 01:22:20,740
the quarterly review, they don't care about your policy document, they don't care that the owners

1910
01:22:20,740 --> 01:22:25,860
will clean it up later, they accelerate whatever is true right now. So AI Ready Governance is not a

1911
01:22:25,860 --> 01:22:30,260
separate program, it is the same control plane patterns you already need, ownership and risk,

1912
01:22:30,260 --> 01:22:37,220
applied specifically to the surfaces, AI amplifies permissions, contents brawl and autonomous execution.

1913
01:22:37,220 --> 01:22:42,340
Start with the part everyone wants to skip, clean permissions before co-pilot scales them. If you're

1914
01:22:42,340 --> 01:22:46,660
rolling out co-pilot into a tenant where everyone links exist, where company wide links exist,

1915
01:22:46,660 --> 01:22:51,300
where guest access drifted and where abandoned teams still have broad membership, you are not doing

1916
01:22:51,300 --> 01:22:55,700
a pilot, you are turning on a discovery engine for your historical mistakes. And you will spend

1917
01:22:55,700 --> 01:23:00,740
the first month doing damage control, not adoption. So the AI Ready move is to baseline what co-pilot

1918
01:23:00,740 --> 01:23:05,540
can see today, not in theory, not via policy intent, in reality what exists, who can reach it and

1919
01:23:05,540 --> 01:23:10,500
what is stale. That baseline has three outputs that matter, first your overshared content surfaces,

1920
01:23:10,500 --> 01:23:15,940
the places where access boundaries are widest. Second, your onalist surfaces, the places where nobody

1921
01:23:15,940 --> 01:23:22,020
can certify intent. Third, your stale surfaces, the places where wrong but grounded answers will come

1922
01:23:22,020 --> 01:23:27,060
from. This is why labels never fixed it. Labels can be part of the posture but labels don't close

1923
01:23:27,060 --> 01:23:32,180
in access path. Labels don't remove an external shared, labels don't fix broken inheritance, labels

1924
01:23:32,180 --> 01:23:36,260
don't delete the five-year-old draft policy that should have been archived. So AI Ready governance

1925
01:23:36,260 --> 01:23:41,540
treats permissions as the first class control and treats content as an asset with life cycle.

1926
01:23:41,540 --> 01:23:46,260
Now here is the part that separates organizations that survive from organizations that flail,

1927
01:23:46,260 --> 01:23:51,860
govern agents before they govern you. Agents are software with reach, they are not helpful assistance,

1928
01:23:51,860 --> 01:23:56,660
they are packaged authorization plus tools plus distribution. So the AI Ready pattern for agents is

1929
01:23:56,660 --> 01:24:01,780
boring and that's why it works. Builders are scoped, environments are tiered, publishing is controlled

1930
01:24:01,780 --> 01:24:06,820
and every agent is inventoryable, reviewable and expirable. If an agent can execute actions,

1931
01:24:06,820 --> 01:24:11,380
it gets treated like a workload identity. It has an owner, it has a life cycle, it has a review cadence,

1932
01:24:11,380 --> 01:24:16,100
it has a retirement plan and if it has no owner it doesn't remain available but forgotten.

1933
01:24:16,100 --> 01:24:21,460
It gets quarantined because unaccountable execution is not a feature. It is a liability. Now the thing most

1934
01:24:21,460 --> 01:24:26,020
people miss is that AI governance changes your audit posture. Traditional audits ask for policy

1935
01:24:26,020 --> 01:24:31,300
configuration and evidence. AI aware audits ask for explainability. Why did this agent have access

1936
01:24:31,300 --> 01:24:35,700
to that data? Why did this user receive that output? Which sources were used? Which tool calls were

1937
01:24:35,700 --> 01:24:40,740
made? Under which identity? That means your controls need to be provable, not just configured.

1938
01:24:40,740 --> 01:24:44,980
You need to be able to show inventory, ownership, review history and enforcement outcomes across the

1939
01:24:44,980 --> 01:24:50,420
tenant. Not we have a setting. Here is the evidence trail. And the evidence trail can't be a scavenger

1940
01:24:50,420 --> 01:24:54,980
hunt across five portals. It has to be a single narrative you can produce on demand. Now outcomes.

1941
01:24:54,980 --> 01:24:59,700
This is where you stay credible by refusing to promise miracles. AI ready governance does not mean

1942
01:24:59,700 --> 01:25:03,780
you will perfectly clean the tenant. It means you can establish a baseline in weeks because you're

1943
01:25:03,780 --> 01:25:09,060
not boiling the ocean. You're isolating the highest risk surfaces first. Overshared,

1944
01:25:09,060 --> 01:25:14,580
onulus, externally exposed and automated. And once you have that baseline you can reduce audit

1945
01:25:14,580 --> 01:25:19,860
prep time from weeks to days because you stop assembling evidence manually and start operating a

1946
01:25:19,860 --> 01:25:24,740
system that logs decisions as part of the governance loop. That's the point. Governance becomes a

1947
01:25:24,740 --> 01:25:29,940
continuous system, not a periodic human event. One more uncomfortable truth before we move on.

1948
01:25:29,940 --> 01:25:35,380
AI will force you to confront the long tail because the long tail is where most risk hides.

1949
01:25:35,380 --> 01:25:41,700
Stale sides. Abandoned teams. Forgotten one drives. Old flows. Old apps. Old agents. AI makes that

1950
01:25:41,700 --> 01:25:46,660
tail visible and actionable to normal users. So your governance response can't be will do a cleaner

1951
01:25:46,660 --> 01:25:51,860
project. It has to be will run a continuous control plane that keeps the tail from growing.

1952
01:25:51,860 --> 01:25:56,900
Ownership enforcement. Risk prioritization. AI specific base lining of what's visible and what's

1953
01:25:56,900 --> 01:26:01,380
executable. That's AI ready governance. And once you accept that the next question is no longer

1954
01:26:01,380 --> 01:26:06,340
philosophical. It's tooling. How do you enforce these patterns continuously across teams,

1955
01:26:06,340 --> 01:26:11,060
SharePoint, Power Platform, Entra and Co-Pilot without becoming the human integration layer?

1956
01:26:11,060 --> 01:26:15,540
That's why a unified governance layer exists. Why a unified governance layer exists, making

1957
01:26:15,540 --> 01:26:19,860
Microsoft governable. So here's where the conversation stops being about individual controls and

1958
01:26:19,860 --> 01:26:25,140
starts being about system design. Native tools are necessary. They are not sufficient. They are

1959
01:26:25,140 --> 01:26:29,780
necessary because you still need entry to issue tokens, purview to define retention and labeling,

1960
01:26:29,780 --> 01:26:35,140
and workload admin centers to expose service specific configuration. No serious architect argues

1961
01:26:35,140 --> 01:26:40,820
otherwise, but sufficiency is the problem. Attendant is not one product. It's an ecosystem of authorization,

1962
01:26:40,820 --> 01:26:45,780
decisions, content surfaces, and automation pathways that constantly create new state. And native

1963
01:26:45,780 --> 01:26:51,460
governance is architected as a set of workload silos, each with partial telemetry, partial policy

1964
01:26:51,460 --> 01:26:55,860
primitives, and partial life cycle features. That's not a moral failing. That's organizational

1965
01:26:55,860 --> 01:27:02,020
reality expressed as software. So when leadership asks, why can't we just use Microsoft native governance?

1966
01:27:02,020 --> 01:27:06,660
The correct answer is not because Microsoft is missing features. The correct answer is because

1967
01:27:06,660 --> 01:27:11,700
the native governance model does not converge into a single control loop. A unified governance layer

1968
01:27:11,700 --> 01:27:16,900
exists because someone has to treat the tenant as one system. That layer has to do four things,

1969
01:27:16,900 --> 01:27:22,340
continuously, first, cross-service inventory, not a monthly export, not a point in time report,

1970
01:27:22,340 --> 01:27:27,540
a living model of teams, groups, sites, one drives, apps, flows, agents, and identity artifacts

1971
01:27:27,540 --> 01:27:31,780
with relationships intact. If you can't see the graph, you can't govern the graph. Second,

1972
01:27:31,780 --> 01:27:36,980
ownership as an enforce primitive, not owners are a column. Owners are a rootable responsibility chain

1973
01:27:36,980 --> 01:27:42,100
that means minimum owners, owner drift detection, escalation paths, and forced reassignment or degradation

1974
01:27:42,100 --> 01:27:50,180
when accountability disappears. Third, life cycle enforcement. Create is easy. Retire is hard.

1975
01:27:50,180 --> 01:27:56,340
A governance layer has to make retirement deterministic, exploration, attestation, archive,

1976
01:27:56,340 --> 01:28:00,260
deletion, and the mechanisms that trigger those outcomes when conditions are met.

1977
01:28:01,060 --> 01:28:06,420
Otherwise sprawl becomes permanent state. Fourth, a risk model that actually maps to consequence.

1978
01:28:06,420 --> 01:28:11,220
Not this violates policy X, risk that incorporates blast radius, sensitivity,

1979
01:28:11,220 --> 01:28:16,820
external exposure, and automation pathways, and then routes work into outcomes. Detect, notify,

1980
01:28:16,820 --> 01:28:21,620
approve, remediate, and prove. That "proof" part matters more than most people admit.

1981
01:28:21,620 --> 01:28:27,060
Audit isn't impressed by intention. Audit cares about evidence who owned it, who approved it when

1982
01:28:27,060 --> 01:28:32,100
it was reviewed, what changed, and what you did about it. A unified layer turns governance from periodic

1983
01:28:32,100 --> 01:28:36,740
observation into continuous enforcement with a trail. And no, this isn't another admin center.

1984
01:28:36,740 --> 01:28:40,900
Architecturally, it is something else. A control plane above the workloads, translating

1985
01:28:40,900 --> 01:28:45,140
ten and wide intent into workloads specific enforcement. It doesn't replace native tools.

1986
01:28:45,140 --> 01:28:48,900
It consumes them, correlates them, and forces the loop to close. That's what making

1987
01:28:48,900 --> 01:28:54,100
Microsoft governable means. Not perfect security. Predictable control. Conclusion.

1988
01:28:54,100 --> 01:28:58,660
Predictable control. Not perfect governance. Governance fails when you mistake configuration

1989
01:28:58,660 --> 01:29:04,020
for control, and Microsoft 365 happily punishes that mistake forever. If you want your tenant to

1990
01:29:04,020 --> 01:29:08,340
become governable, stop chasing settings and start enforcing three primitives, ownership,

1991
01:29:08,340 --> 01:29:13,860
life cycle, and risk-based consequence. Continuously, across every workload. If you want the next

1992
01:29:13,860 --> 01:29:18,420
episode, it'll be a practical walkthrough of the three control patterns and to end. How to

1993
01:29:18,420 --> 01:29:23,540
enforce ownership at scale, how to score risk without drowning in noise, and how to baseline

1994
01:29:23,540 --> 01:29:28,980
co-pilot and agents before they baseline you. Subscribe and listen to next episode.