Auroranexis

The Risks module documents operational threats before they become client-impacting incidents. Register risks with severity and status, assign internal owners, link records to clients, and track mitigation through resolution or dismissal. Open risks contribute to client health signals, SLA evaluation, and operational dashboards used in reviews and governance discussions.

Overview

Each risk record captures title, description, severity, status, client linkage, owner, and due dates where applicable. The Risks list supports filtering by status and severity so operators can prioritize portfolio-wide reviews. Client detail pages show open risks alongside health and SLA context for account-level conversations.

Risks can be created manually by staff or originate from platform signals such as health engine evaluation, SLA breaches, reports, or activity events. Regardless of source, owners are responsible for status progression and documented rationale when closing records.

Severity drives SLA timer evaluation when the linked client has an assigned policy. High and critical risks should appear in weekly operations meetings alongside open incidents. Risk score summaries on client detail pages aggregate open items for quick triage.

Unlike incidents, risks represent potential or emerging threats rather than active client impact. Maintaining accurate distinction between the two keeps SLA metrics, health scores, and client communications aligned with what actually happened versus what might happen.

Purpose

Operational risk tracking gives agencies a defensible record of known issues, mitigation plans, and accepted exposures. It supports internal governance, selective client transparency through published reports, and post-incident analysis when risks were identified but not yet resolved.

Linking risks to clients ensures portfolio views and reports reflect the correct account context. SLA policies apply response targets to open risks based on severity, aligning platform metrics with contractual commitments your team can demonstrate in QBRs.

Risk history also helps agencies avoid repeating mistakes. When a similar issue resurfaces, searchable records show what was tried, who owned mitigation, and why prior records were resolved or dismissed.

Core Concepts

Severity levels

Risk severity definitions

Severity	Description
Low	Minor operational concern with limited client impact; track for awareness.
Medium	Meaningful issue requiring planned mitigation within normal cadence.
High	Significant exposure; prioritize in operations reviews and owner follow-up.
Critical	Immediate attention; may pair with Settings → Escalation rules and leadership review.

Status lifecycle

Risk status values

Status	Description
Open	Identified; mitigation not yet started or confirmed by owner.

Features

Create and edit risks from Risks → New risk with client assignment.
Severity and status lifecycle with activity history.
Internal owner assignment and optional due date tracking.
Client-linked views on portfolio and client detail pages.
SLA timer evaluation based on assigned client policy and severity.
Risk score summaries on client detail pages for open items.
Filtering and search across the organization portfolio.
Integration with reports—related open risks can appear in generated reports.
Manual and platform-originated risk creation with source metadata.
Dismiss workflow with rationale for accepted or invalid risks.
Linkage to incidents when risks materialize into client impact.
Dashboard and health engine integration for portfolio-level visibility.
Role-based permissions for create, update, and close actions.
Audit-friendly activity log on each risk record.

Step-by-step usage

Search existing risks for the client to avoid duplicates before creating a new record.
Open Risks → New risk and enter title, client, severity, and description.
Assign an internal owner responsible for mitigation and follow-up.
Set a due date if your delivery playbook requires time-bound response.
Move status to Acknowledged when work begins; add notes as mitigation progresses.
Monitor SLA timers on the risk detail page if the client has an assigned policy.
Set Mitigated when controls are in place; continue monitoring before final closure.
Resolve or Dismiss with documented rationale when the risk is no longer applicable.
Link related incidents if the risk materializes into active client impact.
Reference significant open risks in client reports when transparency is expected.
Review open risks weekly in operations meetings alongside incidents and SLA breaches.
Use Settings → Escalation rules for critical risks that breach response targets.

Best Practices

Risk registers fail when teams treat them as write-once archives. Successful agencies assign owners, set review cadence, and close loops in the same meeting where incidents are discussed.

Define severity criteria in your internal playbook so the team applies labels consistently.
Review open risks weekly in operations meetings alongside incidents and SLA breaches.
Avoid duplicate records—search by client and title before creating new entries.
Close risks with clear resolution notes suitable for audit or client review.
Escalate critical risks through your defined path including Settings → Escalation rules.
Link related incidents when a risk materializes into client impact.
Use Acknowledged status promptly so SLA timers reflect active ownership.
Dismiss only with written rationale when accepting exposure or invalidating the threat.
Include open high-severity risks in published report key risks sections when appropriate.
Revisit mitigated risks after thirty days to confirm controls remain effective.

Examples

Marketing agency

A marketing agency registers Medium risks when creative capacity conflicts with launch dates, assigns delivery directors as owners, and cites open items in monthly reports. Resolved risks document what staffing changes prevented recurrence before the next campaign cycle.

AI automation agency

An automation agency logs High risks when third-party API dependencies lack fallback paths, links risks to clients running affected workflows, and resolves after redundant integrations are deployed. SLA timers on critical risks trigger escalation to engineering leads.

MSP

An MSP tracks infrastructure risks—end-of-life hardware, missing backups—per client with due dates aligned to maintenance windows. Critical risks escalate through Settings → Escalation while Watch client status signals leadership review on the client record.

Consultancy

A consultancy documents scope creep and key-person dependency as Medium risks during engagements, dismisses accepted exposures with client sign-off noted in resolution text, and references mitigated risks in closeout reports published to portal users.

Enterprise deployment

A large agency standardizes risk titles across regions, requires admin review before Dismiss on High or Critical items, and exports portfolio risk summaries during quarterly governance reviews. Platform-originated risks from SLA evaluation are triaged within defined response windows.

Troubleshooting

Common risks module issues

Problem	Cause	Solution
Cannot edit a risk	Role is read-only for risks module	Contact an admin to verify risks write permissions on your role.
Risk missing from client detail page	Incorrect or missing client linkage	Confirm the correct client is linked on the risk record.
SLA timer not shown on risk	No SLA policy on client	Assign a policy on the client detail page or in Settings → SLA.
Duplicate risks for same issue	Manual creation without search	Merge narrative in one record; dismiss duplicates with documented rationale.
Unexpected platform-created risk	Health engine or SLA evaluation trigger

FAQ

What is the difference between mitigated and resolved?: Mitigated means controls are in place but the team is still monitoring. Resolved means the risk is fully closed with no further action expected.
Do risks appear in the client portal?: Risks are primarily an internal operational record. Client-facing transparency is typically delivered through published reports or incident summaries rather than direct risk portal views.
How do SLA policies apply to risks?: When a client has an assigned SLA policy, open risks evaluate response targets based on severity. Review SLA summaries on the client detail page and in Settings → SLA.
Can I link a risk to an incident?: Incidents can reference linked risks when logging client-impacting events. Use this linkage to maintain traceability from identified risk to realized impact.
Who can dismiss a risk?: Users with risk write permissions can move status to Dismissed. Document why the risk was accepted or deemed not applicable for audit purposes.
When should I create a risk versus an incident?: Create a risk for potential or emerging threats without active client impact. Create an incident when delivery is actively affected or service is disrupted.

Need help?

Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.

Sources and ownership

Risks may be created manually or generated from platform sources including health engine rules, SLA evaluation, reports, activity feeds, and portal submissions. Source metadata helps reviewers understand why a record exists without inferring from the title alone.

Every open risk should have an internal owner accountable for status updates. Due dates optional but recommended when contracts or playbooks require time-bound mitigation.