WEBVTT 1 00:00:00.040 --> 00:00:02.240 Here's a brutal truth. Every time you invite a guest 2 00:00:02.279 --> 00:00:04.960 into Microsoft three sixty five, you might be exposing your 3 00:00:05.000 --> 00:00:07.200 data in ways your compliance team never signed off on. 4 00:00:07.599 --> 00:00:10.519 It's not obvious, and that's exactly the problem. Most organizations 5 00:00:10.560 --> 00:00:13.439 think they've got it locked down until an audit proves otherwise. 6 00:00:13.720 --> 00:00:16.239 In this workshop will break down the hidden traps in 7 00:00:16.399 --> 00:00:19.120 M three sixty five guest Access, why permissions don't always 8 00:00:19.160 --> 00:00:21.640 mean protection, and how to build a framework that keeps 9 00:00:21.640 --> 00:00:24.920 you secure and compliant without slowing your business down. While 10 00:00:25.000 --> 00:00:28.879 guest access looks easy until it isn't. On stage, Microsoft 11 00:00:28.879 --> 00:00:31.559 makes guest access look like magic. A few clicks later 12 00:00:31.600 --> 00:00:33.880 and your external partner is dropping files into teams. The 13 00:00:33.920 --> 00:00:37.439 permissions flow smoothly, and everything feels tightly controlled. In a demo, 14 00:00:37.640 --> 00:00:40.679 it's seamless. In production, it usually lands somewhere between confusing 15 00:00:40.679 --> 00:00:43.520 and risky. That contrast is what catches many admins of Guard. 16 00:00:44.000 --> 00:00:47.000 They see the marketing version lightweight and problem free, then 17 00:00:47.039 --> 00:00:49.679 try it themselves, get a successful test run, and assume 18 00:00:49.719 --> 00:00:53.240 they're protected. The trouble only starts showing up once guests 19 00:00:53.240 --> 00:00:57.359 begin to actually use the environment. Suddenly, boundaries blur guests 20 00:00:57.399 --> 00:01:00.280 move around more freely than anyone expected, and set positive 21 00:01:00.359 --> 00:01:04.319 information appears accessible in ways nobody intended. Think about the 22 00:01:04.319 --> 00:01:06.879 first time someone outside your company actually uses the guest 23 00:01:06.920 --> 00:01:09.519 account you set up. You probably created a test user 24 00:01:09.560 --> 00:01:11.959 shared a folder from teams. Watch the sign in complete 25 00:01:12.280 --> 00:01:15.519 and smiled at how straightforward it seemed. That's the storyline 26 00:01:15.560 --> 00:01:18.640 admin's like to stick with. On paper, it's working as designed, 27 00:01:18.959 --> 00:01:21.719 But real collaboration doesn't stay confined to one file share 28 00:01:21.760 --> 00:01:24.840 or one team. Guests click on links, OpenDocument libraries, switch 29 00:01:24.879 --> 00:01:27.239 between apps, and that's where the gaps start to appear. 30 00:01:27.640 --> 00:01:30.079 The confidence earned in that five minute test drive doesn't 31 00:01:30.079 --> 00:01:32.200 hold up when an actual business partner locks in and 32 00:01:32.200 --> 00:01:35.560 starts exploring. Let's take a very normal request as an example. 33 00:01:35.680 --> 00:01:38.560 A sales partner joins a shared team to handle proposal documents. 34 00:01:38.879 --> 00:01:40.920 At first, everything is as expected. They can see the 35 00:01:40.959 --> 00:01:44.959 sales channels upload into the shared files, message the internal team. Then, 36 00:01:45.200 --> 00:01:48.079 almost casually, they click into the document library behind the team. 37 00:01:48.480 --> 00:01:51.480 Remember team's files live in SharePoint, that one click may 38 00:01:51.519 --> 00:01:54.879 surface directories far beyond the intended scope. In one real case, 39 00:01:54.920 --> 00:01:57.959 the library that stored sales proposals also contained folders holding 40 00:01:58.079 --> 00:02:01.319 HR guidelines, payroll samples, and on VOD scripts. To the 41 00:02:01.359 --> 00:02:04.359 admin who invited them, nothing looked strange. To the guest, 42 00:02:04.439 --> 00:02:07.680 it was all just available. This isn't because Microsoft intended 43 00:02:07.719 --> 00:02:11.000 sensitive data to be exposed. It's because every service applies 44 00:02:11.039 --> 00:02:13.879 its own version of the rules. Teams wraps its permissions 45 00:02:13.879 --> 00:02:18.280 around channels, SharePoint controls access through inheritance. One assumes isolation, 46 00:02:18.360 --> 00:02:21.919 the other assumes continuity. They aren't wrong individually, but put 47 00:02:21.919 --> 00:02:24.599 them together and you get outcomes. Nobody meant to design. 48 00:02:24.759 --> 00:02:27.080 That's why a guest who should only see one narrow 49 00:02:27.080 --> 00:02:29.560 slice of content ends up with a much wider view 50 00:02:29.560 --> 00:02:32.479 than expected. From the admin console, everything looks fine. The 51 00:02:32.479 --> 00:02:36.319 guest account is visibly restricted, the settings show external collaboration limited. 52 00:02:36.439 --> 00:02:39.319 Nothing is technically broken. The problem is the invisible plumbing 53 00:02:39.400 --> 00:02:42.120 beneath it. The system relies on guest identities that live 54 00:02:42.199 --> 00:02:45.360 across multiple layers, and the way those layers interpret permissions 55 00:02:45.360 --> 00:02:48.199 doesn't line up neatly. A team's permission might say yes, 56 00:02:48.280 --> 00:02:51.439 while a SharePoint permission says inherited yes, and the guest 57 00:02:51.560 --> 00:02:54.319 just sees the bigger picture. That bigger picture might include 58 00:02:54.319 --> 00:02:57.639 confidential documents. The business never planned to share. It's tempting 59 00:02:57.639 --> 00:03:00.360 to treat this as a configuration slip. Tweaker said, run 60 00:03:00.400 --> 00:03:03.360 another test confirm the results. In reality, the bigger pattern 61 00:03:03.400 --> 00:03:06.360 is that guest access isn't unified. The defaults are overlapping, 62 00:03:06.479 --> 00:03:10.120 not consistent, and when services collide, they don't negotiate, They 63 00:03:10.199 --> 00:03:13.199 just expose what each one thinks is allowed. That's why 64 00:03:13.479 --> 00:03:16.120 what looks perfect in a demo feels almost broken in 65 00:03:16.159 --> 00:03:19.520 real world use. What's happening underneath isn't just permission mismatches. 66 00:03:19.759 --> 00:03:23.159 It's an entire identity framework operating quietly in the background. 67 00:03:23.560 --> 00:03:27.360 Invitations create one state, authentication creates another, and directory tracking 68 00:03:27.400 --> 00:03:31.280 holds onto both, sometimes long after the collaboration ends. Guests 69 00:03:31.280 --> 00:03:34.199 don't just exist as one clear account. They exist as 70 00:03:34.240 --> 00:03:38.039 different objects across services, stitched together by assumptions that don't 71 00:03:38.039 --> 00:03:40.840 always agree. Most admins never see these layers, but they 72 00:03:40.840 --> 00:03:44.199 explain why external access never feels clean and why it's 73 00:03:44.199 --> 00:03:46.960 so quick to spile out of control when scaled. So 74 00:03:47.280 --> 00:03:49.599 when we talk about guest access being tricky, it's not 75 00:03:49.639 --> 00:03:53.159 because it's on or off. That binary view doesn't capture 76 00:03:53.159 --> 00:03:55.759 the reality. What breaks things is that every service in 77 00:03:55.800 --> 00:03:58.479 Microsoft three sixty five bends those identity layers to its 78 00:03:58.520 --> 00:04:02.039 own defaults, and when those faults don't match, access gets 79 00:04:02.039 --> 00:04:04.879 granted in ways that look inconsistent and often unsafe, which 80 00:04:04.960 --> 00:04:08.000 raises the real question, if guest access isn't just one switch, 81 00:04:08.240 --> 00:04:10.680 what is actually driving all of this? Underneath the surface, 82 00:04:11.319 --> 00:04:13.960 the three identity layers no one talks about the real 83 00:04:14.000 --> 00:04:16.600 puzzle of guest management isn't where most people expect it. 84 00:04:16.720 --> 00:04:20.399 Everyone talks about permissions, team settings or external sharing toggles. 85 00:04:20.680 --> 00:04:24.160 But the real complexity starts much earlier with how identities work. 86 00:04:24.279 --> 00:04:27.720 And that doesn't mean in the broad corporate HR directory sense. 87 00:04:28.079 --> 00:04:30.519 It means the specific layers that make a guest real 88 00:04:30.680 --> 00:04:34.279 Inside Microsoft three sixty five. This is the part many 89 00:04:34.319 --> 00:04:38.240 admins underestimate because it looks straightforward at first glance. You 90 00:04:38.279 --> 00:04:40.920 see a guest account in Azure ad it appears next 91 00:04:40.920 --> 00:04:43.920 to your employees, and you assume job done. What's hiding 92 00:04:44.000 --> 00:04:46.199 under that entry, though, is a three part system that 93 00:04:46.240 --> 00:04:49.120 doesn't behave like the accounts you manage every day. When 94 00:04:49.120 --> 00:04:51.680 most admins picture a guest, they imagine a single user 95 00:04:51.720 --> 00:04:55.160 object you can monitor, govern and remove. That's the assumption 96 00:04:55.360 --> 00:04:57.319 if it shows up in azure AD, then it should 97 00:04:57.360 --> 00:05:00.560 behave like a regular user with fewer permissions. Except that's 98 00:05:00.600 --> 00:05:03.120 only part of the picture. A guest identity isn't one thing. 99 00:05:03.160 --> 00:05:06.199 It's actually three things stitched together, and that stitching is 100 00:05:06.199 --> 00:05:09.720 where access problems appear. Forgetting about one of those layers 101 00:05:09.759 --> 00:05:11.720 is the same as leaving it wide open, because the 102 00:05:11.759 --> 00:05:14.480 whole system relies on all three being aligned. The first 103 00:05:14.519 --> 00:05:16.920 layer starts before the guest even lands in your tenant. 104 00:05:17.240 --> 00:05:20.839 Someone extends an invitation. That action defines who they're allowed 105 00:05:20.839 --> 00:05:22.759 to be and how they prove who they are. It 106 00:05:22.759 --> 00:05:24.560 could be as simple as the guest typing in a 107 00:05:24.600 --> 00:05:28.040 Gmail address, which then roots through their Google credentials for authentication. 108 00:05:28.319 --> 00:05:31.199 Or maybe it's another enterprise tenant where multi factor rules apply, 109 00:05:31.399 --> 00:05:33.439 and that first handshake, the invite, and the method of 110 00:05:33.480 --> 00:05:36.680 authentication sets the baseline of trust. If that's too loose, 111 00:05:36.759 --> 00:05:38.879 everything built on top of it will be weaker than 112 00:05:38.920 --> 00:05:42.000 it looks. The second layer lives in azure AD once 113 00:05:42.000 --> 00:05:44.639 the guest accepts as your AD creates and maintains a 114 00:05:44.639 --> 00:05:47.759 directory object. That object is separate from your employees, and 115 00:05:47.800 --> 00:05:51.000 the way it persists is not as obvious as many think. 116 00:05:51.759 --> 00:05:54.399 Even if the collaboration ends, the object might linger unless 117 00:05:54.399 --> 00:05:57.720 someone actively cleans it up. That means the identity doesn't 118 00:05:57.720 --> 00:06:00.360 disappear just because the project did. You could move their 119 00:06:00.360 --> 00:06:03.319 access to one team, but the directory still recognizes them, 120 00:06:03.399 --> 00:06:06.399 carries forward properties, and holds them as a known entity. 121 00:06:06.720 --> 00:06:09.480 Without a process to review and expire those objects, your 122 00:06:09.480 --> 00:06:13.079 directory becomes a maze of long forgotten contractors who still 123 00:06:13.120 --> 00:06:16.879 technically exist. Then comes the third layer, the application context. 124 00:06:17.199 --> 00:06:19.199 This is where permissions at the app level take over. 125 00:06:19.600 --> 00:06:22.079 A guest may be visible in azure AD, but each 126 00:06:22.120 --> 00:06:25.199 app decides how to interpret that identity. Teams will treat 127 00:06:25.199 --> 00:06:28.439 them as part of a channel with defined access. SharePoint 128 00:06:28.480 --> 00:06:31.519 may extend inherited permissions down a library. One drive could 129 00:06:31.519 --> 00:06:34.360 react differently. Again, this app context is the final door 130 00:06:34.399 --> 00:06:36.959 they walk through, and the door isn't locked just because 131 00:06:37.000 --> 00:06:39.560 you think it was. Upstream, Each app checks the identity, 132 00:06:39.680 --> 00:06:42.000 reads the object, and then applies its own rules. Those 133 00:06:42.079 --> 00:06:43.839 rules don't always match, which is why you end up 134 00:06:43.839 --> 00:06:46.959 with unexpected visibility. Think about a contractor who wraps up 135 00:06:46.959 --> 00:06:50.399 a six month engagement. Their access to the team is removed, 136 00:06:50.600 --> 00:06:53.800 but their sign in methods say their university Outlook account 137 00:06:53.920 --> 00:06:56.920 still ties back. Azure ad still holds their object. The 138 00:06:56.920 --> 00:07:00.000 SharePoint side connected to that team didn't revoke inherited pmer 139 00:07:00.680 --> 00:07:03.600 so six months later, nobody remembers they exist, but technically 140 00:07:03.600 --> 00:07:05.319 they can still see parts of the library. If they 141 00:07:05.319 --> 00:07:08.079 bother to try, nothing in the admin center will flash 142 00:07:08.120 --> 00:07:10.920 red at you. The system believes it's behaving correctly, yet 143 00:07:10.959 --> 00:07:13.040 the door is still open. The best way to picture 144 00:07:13.040 --> 00:07:15.199 this is a door with three locks. One lock is 145 00:07:15.199 --> 00:07:18.000 the invite and authentication, one is azure AD's record, and 146 00:07:18.000 --> 00:07:20.199 one is the app check. All three need to close. 147 00:07:20.360 --> 00:07:22.360 If even one is left dangling, the door looks shut, 148 00:07:22.399 --> 00:07:25.399 but it isn't. That's why life cycle management isn't an 149 00:07:25.399 --> 00:07:27.639 optional extra. It's the only way to make sure those 150 00:07:27.720 --> 00:07:30.759 layers stay in sync. Microsoft doesn't centrally govern it for you. 151 00:07:30.920 --> 00:07:33.240 There's no magic cleanup happening in the background. You need 152 00:07:33.279 --> 00:07:36.120 to build the review process, expiration rules, and off boarding 153 00:07:36.160 --> 00:07:39.360 steps yourself. Most guest access failures trace back here not 154 00:07:39.439 --> 00:07:41.519 because a toggle was misclicked, but because one of these 155 00:07:41.560 --> 00:07:44.079 three layers was overlooked. The system doesn't aught to fix 156 00:07:44.120 --> 00:07:46.639 those gaps, It just tolerates them. So before talking about 157 00:07:46.680 --> 00:07:49.680 policies or compliance, the starting point is recognizing that guest 158 00:07:49.720 --> 00:07:52.759 identity isn't one dimension, it's three, and every one of 159 00:07:52.759 --> 00:07:55.079 them has to be treated as critical. Once you see 160 00:07:55.079 --> 00:07:57.519 that structure clearly, the next headache makes a lot more sense. 161 00:07:57.839 --> 00:08:01.079 Each Microsoft three sixty five service interpret those layers differently, 162 00:08:01.439 --> 00:08:04.839 and that's how collisions between Teams, SharePoint, and Perview begin. 163 00:08:05.959 --> 00:08:09.160 When Microsoft three sixty five services don't agree. What happens 164 00:08:09.160 --> 00:08:11.879 when Microsoft three sixty five services can't agree on what 165 00:08:11.920 --> 00:08:14.759 an external user should see. That's the question that keeps 166 00:08:14.759 --> 00:08:17.839 showing up in production environments. Teams tells you external access 167 00:08:17.879 --> 00:08:21.879 is tightly controlled, SharePoint works off a model of permission inheritance. 168 00:08:22.319 --> 00:08:25.279 Then Perview comes in later and tells you something completely different, 169 00:08:25.639 --> 00:08:28.360 usually pointing out risks after they already happened. It's the 170 00:08:28.399 --> 00:08:31.800 same guest account, but three very different interpretations, and that 171 00:08:31.879 --> 00:08:35.159 mismatch is where things start looking messy. Teams is usually 172 00:08:35.159 --> 00:08:38.960 the poster child for external collaboration. The messaging is simple, 173 00:08:39.039 --> 00:08:41.279 invite a guest into a channel, give them visibility to 174 00:08:41.320 --> 00:08:44.840 specific files and conversations, and keep everything else off limits. 175 00:08:45.200 --> 00:08:47.759 Straightforward enough, but when you step behind the curtain. It's 176 00:08:47.759 --> 00:08:50.759 SharePoint that handles the files. SharePoint doesn't just think in 177 00:08:50.840 --> 00:08:53.799 terms of channels, it thinks in terms of libraries, folders, 178 00:08:53.799 --> 00:08:56.799 and site inheritance, So the need boundaries shown in teams 179 00:08:56.840 --> 00:09:00.200 don't always survive that translation. Suddenly, what looked like a 180 00:09:00.240 --> 00:09:03.960 self contained workspace opens up into something much broader. Guests 181 00:09:04.039 --> 00:09:07.279 don't see the channel wall. They see the underlying library, 182 00:09:07.440 --> 00:09:09.840 complete with folders that might have nothing to do with 183 00:09:09.879 --> 00:09:12.159 the project they're working on. I've seen this play out 184 00:09:12.159 --> 00:09:15.039 in ways that leave admins scratching their heads. One company 185 00:09:15.200 --> 00:09:17.799 swore their external partner only had access to a single 186 00:09:17.840 --> 00:09:20.440 team's channel. That's what the interface showed. But once the 187 00:09:20.480 --> 00:09:23.799 guest clicked open in SharePoint, the entire library behind the 188 00:09:23.799 --> 00:09:26.679 team was accessible. They didn't need to hack anything. Just 189 00:09:26.720 --> 00:09:29.399 clicking naturally led them into areas no one planned for 190 00:09:29.440 --> 00:09:32.639 them to visit payroll templates, hr on boarding packs, internal 191 00:09:32.639 --> 00:09:35.960 policy drafts, all sitting right next to the intended sales files. 192 00:09:36.120 --> 00:09:38.440 To the guest, it wasn't restricted, it was simply there. 193 00:09:39.000 --> 00:09:41.039 To it, it looked like a gaping hole. They didn't 194 00:09:41.080 --> 00:09:45.159 realize existed until someone reported it. Now, where does purview 195 00:09:45.200 --> 00:09:47.360 fit into this. Perview is good at looking back. It 196 00:09:47.360 --> 00:09:50.200 will tell you what data was accessed, whether sensitive labels 197 00:09:50.200 --> 00:09:53.840 were triggered, and report on exposure. That's valuable, but it 198 00:09:53.840 --> 00:09:57.080 doesn't prevent the access upfront. Many admins only find out 199 00:09:57.120 --> 00:10:00.120 about conflicts between teams and SharePoint when a Perview report 200 00:10:00.159 --> 00:10:02.559 lens in their inbox showing that an external account viewed 201 00:10:02.559 --> 00:10:06.120 files marked as confidential. It's not that team settings failed, 202 00:10:06.279 --> 00:10:09.200 it's that Sharepoints inheritance told a different story and Perview 203 00:10:09.279 --> 00:10:12.120 highlighted the contradiction a week later. And this isn't a 204 00:10:12.200 --> 00:10:15.559 random glitch. It's a direct result of fragmentation. Every service 205 00:10:15.559 --> 00:10:17.879 in the MPTY six five ecosystem carries its own version 206 00:10:17.879 --> 00:10:21.879 of access rules. Teams isolates by channel, SharePoint cascades settings 207 00:10:21.879 --> 00:10:25.360 down Exchange has calendar sharing. One Drive defaults to individual 208 00:10:25.399 --> 00:10:28.639 file links. Perview classifies after the fact. None of them 209 00:10:28.639 --> 00:10:31.200 are broken individually, but they weren't built around a single 210 00:10:31.200 --> 00:10:33.960 shared model of external trust, so when you stitch them together, 211 00:10:34.000 --> 00:10:36.440 they don't reconcile. They just pile on top of each other. 212 00:10:36.879 --> 00:10:40.200 Imagine four managers giving the same employee conflicting instructions. One 213 00:10:40.200 --> 00:10:42.879 says you only work in this room. Another hands over 214 00:10:42.919 --> 00:10:44.960 a master key because that's how we've always done it. 215 00:10:45.480 --> 00:10:48.279 A third check slogs on Friday and flags what looked unusual. 216 00:10:48.399 --> 00:10:50.639 The fourth trusts the employee by default because they got 217 00:10:50.639 --> 00:10:53.919 an approved invite. The result isn't oversight, it's chaos. The 218 00:10:53.919 --> 00:10:57.200 employee isn't misbehaving. They're following the signals in front of them. 219 00:10:57.440 --> 00:11:01.000 That's what guests experienced. They aren't exploiting flaw, They're navigating 220 00:11:01.039 --> 00:11:04.240 whatever rules show up on their screen. Often compliance or 221 00:11:04.240 --> 00:11:06.960 audited teams are the first ones to notice. I'd assumes 222 00:11:07.000 --> 00:11:10.519 the settings work as documented. Meanwhile, auditors run a usage 223 00:11:10.519 --> 00:11:14.200 report and ask why external identities accessed sensitive libraries that 224 00:11:14.240 --> 00:11:17.200 were supposed to be locked down. By the time there's surfaces, 225 00:11:17.240 --> 00:11:19.399 it looks like an incident, when in reality, it's just 226 00:11:19.440 --> 00:11:22.320 the convergence of defaults. That gap is painful. The people 227 00:11:22.360 --> 00:11:25.600 responsible for compliance end up discovering governance failures before the 228 00:11:25.639 --> 00:11:28.759 IT team who actually owns the configuration. So the real 229 00:11:28.759 --> 00:11:31.519 issue here isn't one toggle left unchecked. It's the collision 230 00:11:31.519 --> 00:11:34.159 between services that weren't designed with a shared external access 231 00:11:34.200 --> 00:11:37.120 model in mind. As your AD holds the identity teams 232 00:11:37.159 --> 00:11:41.480 advertises control, SharePoint extends access through inheritance, Purview tells you 233 00:11:41.480 --> 00:11:44.639 about it after the exposure to gather these defaults create outcomes. 234 00:11:44.679 --> 00:11:48.120 No single admin intended governance doesn't fail because you've forgot 235 00:11:48.120 --> 00:11:50.840 one box. You can toggle everything correctly and still end 236 00:11:50.879 --> 00:11:54.600 up with conflict. The failure happens because services disagree on responsibility, 237 00:11:55.120 --> 00:11:58.279 and that disagreement creates more than frustration. It creates audited 238 00:11:58.320 --> 00:12:01.440 findings because even if it eventually patches the gap, there's 239 00:12:01.440 --> 00:12:04.440 still no proof of consistent governance during the period of exposure, 240 00:12:04.639 --> 00:12:07.360 which leads us into a different but related challenge. At 241 00:12:07.360 --> 00:12:10.600 some point, technical mismatches stop being a configuration headache and 242 00:12:10.600 --> 00:12:13.519 start becoming a legal one, because aligning service defaults is 243 00:12:13.559 --> 00:12:16.919 only step one. The other battlefield is making sure guest 244 00:12:16.919 --> 00:12:19.519 access meets compliance obligations you can prove in front of 245 00:12:19.559 --> 00:12:23.960 regulators the compliance maze behind guest access. Here's the uncomfortable 246 00:12:24.039 --> 00:12:27.000 side of guest access. In Microsoft three sixty five, every 247 00:12:27.039 --> 00:12:29.759 single external user you invite could come with legal baggage 248 00:12:29.759 --> 00:12:31.879 you went thinking about at the time. It's easy to 249 00:12:31.919 --> 00:12:34.240 focus entirely on whether someone can see a folder or 250 00:12:34.360 --> 00:12:37.279 join a team's channel. The bigger issue is whether giving 251 00:12:37.360 --> 00:12:40.759 them that access was lawful, documented, and defensible if a 252 00:12:40.799 --> 00:12:43.279 regulator or auditor shows up. The scary part is that 253 00:12:43.320 --> 00:12:46.360 compliance isn't just about what happens technically. It's about what 254 00:12:46.399 --> 00:12:48.720 you can prove later, and if the proof doesn't exist, 255 00:12:48.720 --> 00:12:51.759 it's the organization that takes the hit, not the technology. 256 00:12:52.039 --> 00:12:55.480 Regulations create a minefield here. In Europe, rules like GDPR 257 00:12:55.559 --> 00:12:58.639 don't stop at employee data, they cover any external processing 258 00:12:58.679 --> 00:13:01.120 of personal data too. In the US, frameworks such as 259 00:13:01.200 --> 00:13:03.919 HIPPA and state level privacy acts put their own demands 260 00:13:03.919 --> 00:13:05.919 on what you can share, how long you retain it, 261 00:13:06.039 --> 00:13:08.960 and which parties are allowed to see it. For organizations 262 00:13:09.000 --> 00:13:11.679 working globally, inviting a partner into a team may unknowingly 263 00:13:11.679 --> 00:13:14.960 cross multiple jurisdictions at once. The technology doesn't stop you, 264 00:13:15.039 --> 00:13:17.000 but the law might expect you to account for it, 265 00:13:17.279 --> 00:13:21.360 and that expectation means access logs, purpose statements, and documented 266 00:13:21.399 --> 00:13:24.360 approvals that most day to day IT processes don't include. 267 00:13:24.559 --> 00:13:26.960 Here's the gap you often see in real projects. IT 268 00:13:27.080 --> 00:13:31.240 teams obsess over toggles controlling external sharing. They make sure 269 00:13:31.320 --> 00:13:34.799 multi factor authentication applies to guests. They test that download 270 00:13:34.799 --> 00:13:38.840 options are disabled. Technically it looks solid, but when auditors arrive, 271 00:13:38.879 --> 00:13:41.559 they're not asking whether downloads were blocked. They're asking who 272 00:13:41.559 --> 00:13:44.480 approve the access in the first place, what business justification 273 00:13:44.600 --> 00:13:47.039 was logged, and what date offboarding was completed. If that 274 00:13:47.080 --> 00:13:49.720 paper trail doesn't exist, then the organization is already out 275 00:13:49.720 --> 00:13:52.639 of compliance, regardless of how clean the technical controls were. 276 00:13:52.960 --> 00:13:55.480 That's the painful reality. Governance can look airtight from an 277 00:13:55.519 --> 00:13:58.799 admin view while still collapsing under regulatory scrutiny. Picture a 278 00:13:58.799 --> 00:14:01.720 design team sharing sensitive if CAT files with an external vendor. 279 00:14:02.120 --> 00:14:05.480 The project moves quickly, collaboration works, and everything feels on track. 280 00:14:05.879 --> 00:14:08.720 Six months later, an auditor asks for proof that the 281 00:14:08.799 --> 00:14:11.679 vendor had explicit consent to handle those files and that 282 00:14:11.759 --> 00:14:13.720 the access was removed at the end of the contract. 283 00:14:13.919 --> 00:14:16.639 The IT team can show when the SharePoint link was created, 284 00:14:16.679 --> 00:14:19.399 but they can't show a documented approval. They can't demonstrate 285 00:14:19.440 --> 00:14:23.279 a lawful basis like contractual necessity or explicit consent. They 286 00:14:23.279 --> 00:14:26.200 don't have a checklist proving that user identities were removed 287 00:14:26.200 --> 00:14:29.679 from the tenant on time. From an audit perspective, that's 288 00:14:29.679 --> 00:14:32.279 a failure. Even if the files were never misused, and 289 00:14:32.320 --> 00:14:35.759 this is where compliance requirements diverge from technical access. It's 290 00:14:35.799 --> 00:14:37.919 not about whether a guest can log in or whether 291 00:14:37.960 --> 00:14:40.919 certain permissions were restricted. It's about being able to show 292 00:14:41.000 --> 00:14:44.759 lawful processing of data, enforcing where the data resides, and 293 00:14:44.879 --> 00:14:48.120 proving that retention periods were respected. If that access crosses 294 00:14:48.159 --> 00:14:51.679 regional boundaries, you may also need to demonstrate data residency 295 00:14:51.720 --> 00:14:54.759 controls were in place. For offboarding. You can't simply click 296 00:14:54.919 --> 00:14:58.600 remove user. You need to show retention proof offboarding, meaning 297 00:14:58.600 --> 00:15:01.519 an audit trail that confirms when and why access ended 298 00:15:01.559 --> 00:15:04.480 and how the directory object was handled. The trap many 299 00:15:04.519 --> 00:15:07.919 admins fall into is assuming that because Microsoft allows a configuration, 300 00:15:08.279 --> 00:15:11.360 it must be compliant. That's never been true. Microsoft provides 301 00:15:11.360 --> 00:15:14.240 the toolbox. Compliance rests on how that toolbox is used 302 00:15:14.240 --> 00:15:17.600 and documented legal obligations. Don't care if the platform technically 303 00:15:17.600 --> 00:15:20.240 supports it. They care if you had permission to process 304 00:15:20.240 --> 00:15:22.879 personal data, retained it only as long as needed, and 305 00:15:22.919 --> 00:15:26.039 then off boarded it responsibly. Even if you locked down 306 00:15:26.080 --> 00:15:30.759 file sharing perfectly without records proving lawful access decisions, you're exposed. 307 00:15:31.000 --> 00:15:34.039 Think of compliance as a shadow layer around your technical setup. 308 00:15:34.159 --> 00:15:36.600 It isn't visible in the admin center. It doesn't surface 309 00:15:36.600 --> 00:15:39.639 in team settings, but it's sitting on top of every invite, 310 00:15:39.639 --> 00:15:42.840 every file share, every guest addition, and it carries equal 311 00:15:42.879 --> 00:15:45.799 weight in whether you've succeeded or failed. Governance that stops 312 00:15:45.840 --> 00:15:49.120 at access controls misses this shadow layer entirely. That's why 313 00:15:49.159 --> 00:15:51.879 so many organizations who feel confident about their tenant are 314 00:15:51.919 --> 00:15:54.919 blindsided during an audit. They focused on permissions, not on proof. 315 00:15:55.399 --> 00:15:58.519 And here's the twist. Organizations rarely fail audits because a 316 00:15:58.559 --> 00:16:01.759 guest secretly exfiltrated day. They fail because nobody can show 317 00:16:01.799 --> 00:16:05.519 documented approval, lawful purpose, or structured off boarding. Auditors aren't 318 00:16:05.519 --> 00:16:08.120 looking for dramatic breaches. They're looking for whether the rules 319 00:16:08.159 --> 00:16:11.320 were followed in a repeatable, verifiable way. In other words, 320 00:16:11.440 --> 00:16:14.080 compliance failures don't come from outside hackers. They come from 321 00:16:14.120 --> 00:16:17.600 gaps in internal processes. Understanding that compliance layer is central 322 00:16:17.600 --> 00:16:20.519 to building guest governance that lasts, but acknowledgment on its 323 00:16:20.519 --> 00:16:23.600 own doesn't fix anything. Recognizing obligations is the start. The 324 00:16:23.639 --> 00:16:26.720 harder part is designing policies that scale to hundreds or 325 00:16:26.720 --> 00:16:30.720 thousands of external users without collapsing under endless manual approvals 326 00:16:31.080 --> 00:16:33.679 and That's where the next challenge emerges. How to create 327 00:16:33.720 --> 00:16:36.679 policies that protect your data, hold up legally, and still 328 00:16:36.759 --> 00:16:39.440 let the business move as fast as it needs designing 329 00:16:39.440 --> 00:16:42.279 scalable policies without security holes. So how do you set 330 00:16:42.320 --> 00:16:44.519 up guest access in Microsoft three sixty five in a 331 00:16:44.519 --> 00:16:47.120 way that works at scale without your IT team drowning 332 00:16:47.320 --> 00:16:50.639 under hundreds of approval tickets. That's where the challenge really 333 00:16:50.639 --> 00:16:53.440 starts to show up. In bigger organizations. It's tempting to 334 00:16:53.480 --> 00:16:56.000 push the slider to one extreme or the other, lock 335 00:16:56.039 --> 00:16:58.720 everything down so tight that nobody can collaborate without weeks 336 00:16:58.759 --> 00:17:01.519 of admin involvement, or open the doors wide to keep 337 00:17:01.559 --> 00:17:05.039 business moving smoothly. Both parts fail over time. One breaks 338 00:17:05.079 --> 00:17:08.640 productivity and frustrates your users. The other leaks identity objects 339 00:17:08.680 --> 00:17:11.720 and drives uncontrolled access across your tenant. The whole point 340 00:17:11.720 --> 00:17:14.240 of scaling policies is to avoid that trap. When you 341 00:17:14.279 --> 00:17:17.880 push security controls too far, the business starts finding workarounds. 342 00:17:17.960 --> 00:17:20.839 You'll see people sending files through shadow it, using personal 343 00:17:20.839 --> 00:17:23.839 one drive accounts, or spinning up separate collaboration portals because 344 00:17:23.839 --> 00:17:26.920 the official process feels too slow. That's not only painful, 345 00:17:27.000 --> 00:17:29.640 it's actually less secure in the long run. Swing the 346 00:17:29.680 --> 00:17:32.480 other way, though, and you introduce guests with broad default 347 00:17:32.559 --> 00:17:35.319 access who nobody remembers to review. You get project folders 348 00:17:35.319 --> 00:17:38.039 still visible months after the project ended. By the time 349 00:17:38.160 --> 00:17:41.039 someone notices the damage in terms of risk exposure is 350 00:17:41.079 --> 00:17:44.160 already done. It's not that access was broken, it's that 351 00:17:44.160 --> 00:17:47.559 the policy couldn't scale to real usage. Imagine a multinational 352 00:17:47.599 --> 00:17:50.720 company working with two hundred external contractors in a given quarter. 353 00:17:51.440 --> 00:17:54.200 If your model relies on manually approving each identity and 354 00:17:54.240 --> 00:17:57.640 manually scheduling off boarding reminders, it collapses under its own weight. 355 00:17:57.839 --> 00:18:00.160 Even if the first ten accounts are processed correctly, By 356 00:18:00.160 --> 00:18:02.240 the time you get to fifty, the review mistakes and 357 00:18:02.279 --> 00:18:05.519 oversight gaps appear. At two hundred, You're no longer governing access, 358 00:18:05.519 --> 00:18:08.720 You're firefighting emails, slip through tickets are stuck waiting, and 359 00:18:08.759 --> 00:18:11.359 nobody has visibility into who still belongs in the tenant. 360 00:18:11.640 --> 00:18:14.759 That's not sustainable. The smarter approach is to classify scenarios 361 00:18:14.759 --> 00:18:18.160 instead of defaulting to one policy. Start by separating guest 362 00:18:18.359 --> 00:18:21.880 access from other kinds of external collaboration. A true guest 363 00:18:21.920 --> 00:18:24.359 might be someone entering a single team for a limited project. 364 00:18:24.759 --> 00:18:27.599 External user accounts could cover long term partners who need 365 00:18:27.680 --> 00:18:31.559 repeated access to core resources. Shared channels introduce yet another 366 00:18:31.680 --> 00:18:34.839 layer with their own permission logic. Treating all three as 367 00:18:34.920 --> 00:18:38.519 the same problem results in chaotic policies. By carving them 368 00:18:38.559 --> 00:18:41.640 into groups, you can apply different tiers of control. High 369 00:18:41.640 --> 00:18:44.359 trust partners might get streamlined on boarding, while ad hoc 370 00:18:44.359 --> 00:18:47.400 project guests need expiration dates and extra reviews. The real 371 00:18:47.440 --> 00:18:50.240 gain comes once you combine these scenario types with automation. 372 00:18:50.680 --> 00:18:53.759 Microsoft provides life cycle rules, but they only matter if 373 00:18:53.799 --> 00:18:57.200 you actually enforce them. Set policies that expire guest accounts 374 00:18:57.200 --> 00:19:00.880 after a set period unless ownership confirms renewal. Use access 375 00:19:00.920 --> 00:19:03.799 reviews to prompt project leads to validate who still belongs. 376 00:19:04.240 --> 00:19:07.960 Trigger background automation to strip unused accounts from sensitive groups. 377 00:19:08.319 --> 00:19:11.440 Done consistently, this reduces what's known as security drift, those 378 00:19:11.480 --> 00:19:14.880 gradual misalignments that creep in when objects pile up unmonitored. 379 00:19:15.200 --> 00:19:18.279 Automation doesn't just lighten the workload, it makes sure policies 380 00:19:18.319 --> 00:19:21.279 actually stick. Think of guest access at scale the way 381 00:19:21.319 --> 00:19:24.400 airport security is structured. Trusted staff don't go through the 382 00:19:24.400 --> 00:19:27.680 same checkpoints as first time travelers. Frequent flyers often have 383 00:19:27.759 --> 00:19:31.000 expedited lanes with different screening. Unknown travelers go through the 384 00:19:31.039 --> 00:19:33.880 full set of checks. Everyone ends up inside the airport, 385 00:19:33.960 --> 00:19:36.759 but the trust model changes how smooth their journey is. 386 00:19:37.119 --> 00:19:39.720 Guest access should mirror that. If you try to put 387 00:19:39.759 --> 00:19:43.000 everyone through the same line, you'll either clog operations or 388 00:19:43.079 --> 00:19:46.200 wave people through without enough scrutiny. Different lanes based on 389 00:19:46.240 --> 00:19:49.319 known risk are what keep traffic flowing without compromising safety, 390 00:19:49.400 --> 00:19:52.920 without designing around scale the small problems multiply ten guests 391 00:19:53.000 --> 00:19:56.240 missing expiration dates doesn't sound dramatic, but repeat that pattern 392 00:19:56.279 --> 00:19:59.279 with hundreds of contractors across multiple projects, and you build 393 00:19:59.319 --> 00:20:03.519 systemic rips. Those risks don't announce themselves with flashing alerts. 394 00:20:03.559 --> 00:20:07.480 They quietly accumulate until compliance officers or internal auditors find them. 395 00:20:07.799 --> 00:20:10.240 By then the work to unravel the overlaps is massive. 396 00:20:10.599 --> 00:20:13.920 What hurts organizations in audits isn't usually one glaring breach, 397 00:20:14.000 --> 00:20:16.319 but the hundreds of minor, unmanaged cases that show the 398 00:20:16.359 --> 00:20:20.160 policies never scaled. The payoff is clear scalable guest policies 399 00:20:20.200 --> 00:20:23.400 rely on automation and scenario based tiers, not broad on 400 00:20:23.640 --> 00:20:27.680 off switches. Success doesn't come from having the tightest config screen, 401 00:20:28.039 --> 00:20:31.079