A security review done “sometime after launch” is a forensic exercise. Done in the fortnight before the first login, it is a checklist. This one orders the questions the way an incident would arrive at them — identity first, boundaries second, content third — so the walk takes minutes rather than weeks.
Identity: who can knock at all
Everything begins with the sign-in path.
- Multi-factor authentication on every account, no grandfather clause. Convenience exceptions become the incident report.
- Join paths — how an account becomes a member. Self-service invite? Then who audits the invites? A monthly list of “who joined, who invited them” costs nothing and answers the uncomfortable questions early.
In practice
Test recovery once, deliberately. Lose the phone, walk the recovery flow, and see who receives the request. Half of abandoned-account incidents are recovery-process incidents wearing a different label.
Boundaries: what crosses the line
Approvers name three flows worth naming: guests in, files out, apps out. Guests get a provisioning ritual (see chapter 18). Outbound file sharing gets a scope (see chapter 10). Apps get a data review — a connector that posts messages out of your workspace also carries your conversation content to a third party, which is a boundary decision, not a widget.
Content protection and visibility
- Retention and eDiscovery rules — who can erase a record, and who can find one later.
- Recording permissions — where files land and who reaches them.
- Admin visibility — what you, as an operator, can see when you must. Know it before an employee asks (chapter 20).
Write down the date you walked this list. A checklist without a date is a poster; a dated one is an audit trail.
