Operating principles
Least privilege
Use the organization-scoped admin role for organization work. Use super admin only when the task crosses an organization boundary or requires platform control.
Explicit organization context
Select the target organization before acting. When no organization is selected, treat cross-organization views as a platform overview—not as permission to edit everything casually.
Audit everything
Administrative, user, report, presentation, template, schedule, and organization changes are governance events. Record the reason and ticket or change reference in your approved system.
Protect secrets
Never place passwords, API keys, private keys, session tokens, or connection strings in Decision Lighthouse content or support notes.
Organizations
Create an organization
- Open the Admin Dashboard and confirm you are signed in as a super admin.
- Create the organization with its approved name and domain. Verify the domain before onboarding users.
- Configure organization-level settings, including an HTTPS PATHScan URL when applicable.
- Create the first organization admin. Confirm the target organization and role before saving.
- Verify the organization appears in the organization list and that the user count and status are correct.
Select and inspect an organization
Use organization selection for scoped user lists, statistics, assessments, reports, tasks, and operational review. Before making a change, confirm the selected organization in the dashboard and the user or resource identity in the response.
Delete an organization
Users and identity
Create or import users
- Create users in the correct organization with the minimum necessary role. Normal user creation provisions the identity through Auth0 and can show a pending provisioning state.
- Use CSV import for a controlled batch. Validate email, name, role, module, and trial date before importing. The supported module is cybersecurity.
- Do not create a super admin for normal organization work. Assign that role only through an approved platform access process.
- After provisioning, verify the user’s active state, role, organization, and login status.
Update, disable, reset, and delete
- Update: change name, role, active state, module, permissions, organization, or trial expiration only when the change is authorized.
- Disable: deactivate access promptly when a user leaves or no longer has a business need.
- Reset: use the supported reset-password action. The user must follow the Auth0 or local password flow and change temporary credentials as required.
- Delete: cannot delete your own account. Deleting a user clears foreign-key ownership references but preserves audit and invitation/signup records for auditability.
- Transfer: organization transfer changes the user’s tenant context. Confirm the receiving organization, business owner, and downstream access before committing.
Trial and access lifecycle
Set and review trial expiration dates deliberately. A newly created user defaults to 30 days when no date is provided. When changing a trial date, communicate the effective date to the organization owner and record the reason outside of Decision Lighthouse’s secret-bearing fields.
- Review organizations with upcoming expirations.
- Confirm the organization’s contract or access approval before extending access.
- Disable inactive accounts rather than leaving unused access active.
- Check Auth0 provisioning status before diagnosing a login problem as an application problem.
Reports, assessments, and presentations
Super admins can review cross-organization history when platform support or governance requires it. Prefer the narrowest organization filter and the smallest necessary time range.
- Use report detail and assessment history to reconstruct a decision journey.
- Use report HTML export or stakeholder presentations only for approved recipients and approved retention purposes.
- Presentation generation requires a completed assessment. Confirm the stakeholder audience before selecting a presentation type.
- Review report deletion requests for retention, legal hold, incident response, or audit requirements before deleting.
- When a report has missing historical interview data, allow the detail view to backfill or recover it through the supported application flow rather than editing storage manually.
Governance controls
Audit logs
Use audit logs to investigate user changes, report actions, organization changes, scheduling, webhooks, templates, and other administrative events. Preserve the evidence needed for the platform’s governance policy.
Scheduled reports
Review schedules for organization, recipients, cadence, and scope. Remove schedules that no longer have an owner. Confirm that generated reports do not exceed the recipients’ authorization.
Webhooks
Validate endpoint ownership and security before enabling a webhook. Treat the destination as a data processor: confirm classification, transport security, access controls, and incident contacts.
Presentation templates
Manage organization templates only after checking file type, size, branding, and owner approval. Keep organization templates scoped to the intended organization.
Vulnerability and remediation operations
- Review or establish the organization’s vulnerability policy with the security owner.
- Confirm governance documents and vulnerability lists are authorized before analysis. Source bytes and descriptions should not be treated as retained records.
- Check rejected-row validation notices before approving a prioritization.
- Use approved history, comparison, and captured outcomes to support remediation governance.
- When an outcome changes the organization’s future decision policy, document that change in the organization’s approved governance process rather than silently changing historical decisions.
Strategic Plan Prioritization operations
Super admins should help organizations understand the privacy boundary and decision mechanics:
- The source plan or pasted text is used for extraction and analysis but is not saved as an approved ranking record.
- The interview is adaptive, bounded, and capped at 10 questions.
- Ranking requires a server-calculated 100% context score.
- Unknowns remain unknown; dependencies are displayed by name, and inferred dependencies do not automatically change scores.
- Only an explicitly approved derived ranking is retained for comparison, with its name, rationale, and approval date.
Security and incident response
- Use Auth0 status and provisioning information when troubleshooting identity.
- Do not ask users to paste credentials, tokens, or private keys into chat, tickets, reports, or Decision Lighthouse fields.
- Use organization-scoped views first and avoid downloading broad cross-tenant data.
- For an unexpected access or data-boundary event, preserve audit entries, identify affected organization and users, disable access if authorized, and follow the organization’s incident process.
- Do not make direct database edits to repair application state unless the approved engineering recovery process explicitly requires it.
Super admin runbook
| Situation | Safe first response |
|---|---|
| User cannot sign in | Check active state, organization, role, Auth0 provisioning status, and trial expiration before resetting the password. |
| Admin sees the wrong organization | Confirm session organization and selected organization, then inspect the server-scoped response and audit log. |
| Report should be removed | Check retention and legal-hold requirements, confirm the report/organization, then use the supported delete action. |
| Organization should be retired | Export or retain required records, remove users through the approved process, verify the organization is empty, then request deletion approval. |
| Webhook or schedule is suspicious | Disable or remove it if authorized, preserve the audit record, validate the destination owner, and follow incident response. |
Decision Lighthouse documentation