Governance
Two pages under the organization sidebar's Govern group keep your MSSP operation accountable and identifiable: the Audit Log, an organization-level record of administrative actions taken through the org console, and Org Settings, your organization's identity and profile.
Both are read-heavy by design. Day to day you will mostly land here for two reasons: reconstructing a change ("which of our admins touched that tenant's policy, and when?") and quoting identity facts to your Surface provider or an auditor (organization ID, seat pool, tenant count). Everything else in the org console writes to these pages implicitly - each management action leaves an audit entry, and the profile reflects your current footprint.
Together they answer the two questions every MSSP eventually gets asked - "who changed this, and when?" and "what exactly is this organization's footprint?".
Access at a glance:
| Page | View | Change |
|---|---|---|
| Audit Log | Any organization admin | Nobody - the trail is append-only |
| Org Settings | Any organization admin | Organization owner (name only; the rest is managed by Surface) |
Audit Log
The Audit Log (Govern > Audit Log) records "org-level and cross-tenant administrative actions across your managed tenants": organization policy and template changes, admin and access changes, branding, SSO, alert-routing and tenant-group changes, and edits to the organization profile itself. Entries are written by the platform itself and attributed to the signed-in admin who performed the action - they cannot be edited or suppressed from the console.
This is separate from each tenant's own audit log. The org Audit Log is the aggregated organization-side trail; when an org action affects a specific tenant, a corresponding entry is also written into that tenant's own audit log, so a tenant's security team retains full visibility of what its MSSP did without needing org access.
| Org Audit Log (this page) | Tenant audit log | |
|---|---|---|
| Who can read it | Organization admins | That tenant's admins |
| Covers | All org-console actions, across all your accessible tenants | Actions inside that tenant, plus copies of org actions that affected it |
| Purely org-level actions (org rename, org sign-in SSO, org default brand) | Recorded with an Org-level badge | Not present |
| Tenant-affecting org actions (policy deploys, tenant SSO, tenant branding) | Recorded with the tenant identifier | Recorded as a per-tenant copy |
[SCREENSHOT PLACEHOLDER: The org Audit Log table with the Time, Actor, Action, Entity, Tenant, and Detail columns visible, including at least one row showing the "Org-level" badge in the Tenant column and one row with a tenant ID.]
How it works
Every entry captures:
| Column | Contents |
|---|---|
| Time | When the action happened, shown as a relative time (hover for the exact timestamp). |
| Actor | The email of the org admin who performed the action. |
| Action | A dotted action name, e.g. org_policy.create or org_alert_route.update. |
| Entity | What was acted on - the entity type plus its identifier. |
| Tenant | The affected tenant's identifier, or an Org-level badge for actions that are purely organizational. |
| Detail | A short human-readable description of the change. |
The table is server-paginated at 25 entries per page, with Previous / Next controls and a running count ("Page 2 of 14 - 340 entries").
Using the page
The Search card ("Filter the trail by action or entity type") has two filter inputs:
- Action - the exact action name, e.g.
org_policy.createorpolicy_template.deploy. Filters match the full value, so include the suffix (.create,.update,.delete). - Entity type - the exact entity type, e.g.
org_policyororg_alert_route.
Changing a filter resets you to page one. You can also hide columns you do not need via the column toggle, and click column headers to sort the currently loaded page.
Common action families you will see in the trail:
| Action prefix | Written when |
|---|---|
org_policy.* | An organization baseline policy is created, updated, or deleted |
policy_template.* | A policy template is deployed to tenants or rolled back |
org_alert_route.* | An alert route is created, updated, or deleted |
org_sso_config.* / org_sso_login_config.* | A managed tenant's or the organization's own SSO provider changes |
org_branding.update | The org default or a tenant's branding changes |
org_admin.* | An organization admin account or its access changes |
org_group.* | A tenant group is created, updated, or deleted |
org.update | The organization profile (for example its name) is edited |
Worked example: who deployed that policy? A tenant complains that a stricter blocking policy appeared overnight. On Govern > Audit Log, enter policy_template.deploy in the Action filter. The matching row shows the actor's email, the deployment time, the affected tenant, and the template named in Detail - enough to answer the customer in one screen, and the same event is visible to the tenant in its own audit log.
Worked example: evidence for a compliance review. An auditor asks who has changed authentication settings this quarter. Filter Entity type by org_sso_login_config to list every change to the organization's own sign-in providers, then repeat with org_sso_config for managed-tenant SSO changes. Each row names the actor, the time, and (for tenant SSO) the affected tenant - screenshot the filtered pages as evidence.
[SCREENSHOT PLACEHOLDER: The Search card with an action filter typed in (e.g. "org_alert_route") and the table narrowed to matching entries.]
Audit Log FAQ
Can entries be deleted or edited? No. The console offers no way to modify the trail; entries are written server-side as actions happen.
Why do some rows say "Org-level" instead of naming a tenant? Actions that are purely organizational - renaming the organization, changing org sign-in SSO, editing an org-default brand - do not belong to any single tenant.
Do tenant admins see this log? No. They see their own tenant audit log, which includes the per-tenant copies of org actions that affected them - see tenant audit log.
Can I export the trail? Not from this page. Page through it in the console; for continuous evidence collection, each tenant's own events can be forwarded through SIEM integration.
My filter returns nothing but I can see matching rows unfiltered.
Both filters are exact-match. org_alert_route in the Action field matches nothing - the action values include the operation suffix, e.g. org_alert_route.update. Put the bare family name (org_alert_route) in Entity type instead.
Org Settings
Org Settings (Govern > Org Settings) holds "general settings for your organization" - a single Organization card with your identity and profile.
[SCREENSHOT PLACEHOLDER: The Org Settings page showing the Organization card with the editable Organization name field and the read-only Slug, Status, Managed tenants, Seat pool, Created, and Organization ID fields.]
Using the page
One field is editable:
- Organization name - your display name across the org console (1-255 characters). Edit it and select Save changes; a "Saved." confirmation appears. Only an organization owner can edit it - everyone else sees the page read-only ("Only an organization owner can edit these.").
[SCREENSHOT PLACEHOLDER: The Organization name field edited with the "Save changes" button active, and the "Saved." confirmation after saving.]
The remaining fields are read-only, "managed by Surface":
| Field | Meaning |
|---|---|
| Slug | Your organization's URL-safe identifier. Also used when resolving pre-login branding from the console address. |
| Status | The organization's lifecycle status (normally active). |
| Managed tenants | How many tenants your organization currently manages. |
| Seat pool | The licensed seat pool shared across your tenants, or Unlimited when no pool is set. Per-tenant allocation lives on the Licensing page. |
| Created | When the organization was created. |
| Organization ID | The unique identifier to quote in support requests. |
If you need the read-only values changed - a new slug, a larger seat pool, a status change - contact your Surface provider; they are provisioned outside the org console.
The Managed tenants and Seat pool values here are the same figures that drive the Licensing page's per-tenant allocation view; when the numbers look off, start there - see the MSSP console overview.
Worked example: rebranding after an acquisition. Your MSSP is acquired and renamed. On Govern > Org Settings, an organization owner changes Organization name from Acme MSSP to Aperture Managed Security and selects Save changes. The rename is recorded in the Audit Log as an org-level entry. Note the Slug does not change - so existing branded sign-in addresses keep working - and customer-visible branding is updated separately on the Branding page.
Org Settings FAQ
Who can see the Govern pages? Any organization admin can open both pages. Only editing is restricted: the organization name requires the owner role, and the Audit Log cannot be edited by anyone.
Why can't I edit the slug or seat pool? They anchor licensing and address-based brand resolution, so they are managed by your Surface provider rather than being self-service.
I renamed the organization - why do sign-in pages still show the old name? The sign-in page shows the Display name from Branding, not the organization name. Update the brand's display name too.
Where do I manage the admins who can access these pages? Organization admins, roles, and per-tenant access are managed on the Admins & Access page - see the MSSP console overview.
Related pages
- MSSP console overview - signing in, the tenant switcher, and the Monitor pages
- Alert Routing, Branding, and Organization SSO - the org-console features whose changes populate the Audit Log
- Tenant audit log - the per-tenant view your customers see