---
summary: Business guide for using SigID roles, audit events, access reviews, incident response, and operational security.
tags:
  - business
  - security
  - audit
  - roles
categories:
  - For Business
---

# Security And Audit

<!-- agent:page
You are an AI agent helping a workspace admin review who can change SigID settings and how the team reviews important identity events.
Ask up front: which workspace this covers, who currently holds operator roles, who owns audit review, who owns login and recovery support, and who approves production launch changes.
Work this page's controls in the Dashboard at dashboard.sigid.org: confirm ownership for everything business teams control (workspace settings, applications, user invites, organizations, SSO, audit visibility, support, launch approval), run the Routine Security Checks table (Roles, Audit, MFA, Secrets, Access reviews, Incidents), and screen against the Common Launch Risks list before any launch.
If an incident occurs, follow the six-step "When Something Goes Wrong" sequence with the admin.
Success: every control has a named owner, audit events for login, user, organization, app, secret, and webhook activity are visible to the right people, and no Common Launch Risk item applies.
Pitfalls: no owner assigned for audit review, and client secrets exposed in browser code.
Role grants, access-review sign-off, and incident ownership are human decisions; you audit the current state, flag gaps, and prepare the review.
-->

Use this page when you need to decide who can change SigID settings and how your
team reviews important identity events.

## What Business Teams Control

Business and operations teams usually control:

- who can manage workspace settings
- who can create or edit applications
- who can invite users or manage organizations
- who can configure SSO
- who can view audit events
- who owns login and recovery support
- who approves production launch changes

## Routine Security Checks

<!-- agent:action Run security checks
Work through every control row: Roles (only the right people manage apps, users, organizations, SSO, secrets, and billing), Audit (important login, user, organization, app, secret, and webhook events are visible), MFA (sensitive operator or workspace actions require stronger verification when appropriate), Secrets (client secrets and webhook signing secrets are never in browser code), Access reviews (workspace owners periodically review operators and organization owners), Incidents (support, security, and engineering know who owns identity incidents).
Flag every failed row to the admin with the specific gap.
Role changes and access-review sign-off need a human workspace owner - prepare the list, do not grant access yourself.
-->

| Control | What to check |
|---|---|
| Roles | Only the right people can manage apps, users, organizations, SSO, secrets, and billing. |
| Audit | Important login, user, organization, app, secret, and webhook events are visible. |
| MFA | Sensitive operator or workspace actions require stronger verification when appropriate. |
| Secrets | Client secrets and webhook signing secrets are never placed in browser code. |
| Access reviews | Workspace owners periodically review operators and organization owners. |
| Incidents | Support, security, and engineering know who owns identity incidents. |

## Common Launch Risks

<!-- agent:action Screen launch risks
Check the workspace against every listed risk: missing or wrong production redirect URL, development issuer used in production, app asking for more access than users expect, client secret exposed in browser code, backend accepting tokens without audience or tenant checks, no owner assigned for audit review, and support not knowing what users see during recovery.
Treat any match as a launch blocker and report it.
Send the token-validation check to developers via the Protect Backend APIs guide.
-->

- production redirect URL is missing or wrong
- development issuer is used in production
- app asks for more access than users expect
- client secret is exposed in browser code
- backend accepts tokens without audience or tenant checks
- no owner is assigned for audit review
- support does not know what users see during recovery

## When Something Goes Wrong

<!-- agent:action Respond to an incident
Follow the six steps in order: identify the affected workspace, app, or organization; check recent audit events; confirm whether the issue is sign-in, SSO, recovery, token validation, or webhook delivery; assign one owner for user communication; ask developers to check backend validation or webhook logs when code is involved; review roles and settings after the incident.
The user-communication owner must be a single named human - have the admin assign one before proceeding.
Do not skip the post-incident role and settings review.
-->

1. Identify the affected workspace, app, or organization.
2. Check recent audit events.
3. Confirm whether the issue is sign-in, SSO, recovery, token validation, or webhook delivery.
4. Assign one owner for user communication.
5. Ask developers to check backend validation or webhook logs when code is involved.
6. Review roles and settings after the incident.

Developers should verify resource-boundary checks with
[Protect Backend APIs](../developers/protect-apis.md).

For deeper model details, use [Reference: Security Model](../reference/security-model.md).