GRC Foundations
A practical explanation of governance, risk, compliance, and assurance inside Aegis, with a clear view of how dashboards, My Work, and workspaces connect.
Role-based learning tracks
Move through ordered modules tailored to the accountability and judgement of each Aegis role.
Operational lessons
Use step-by-step articles, walkthrough placeholders, and checklists that map directly to live workflows.
Playbooks and reference guides
Connect structured learning with the deeper Knowledge Library when a team needs implementation detail.
GRC Foundations
Use this section to understand how work actually moves through Aegis. Aegis is not a document archive. It is the operating system where governance, risk, compliance, and assurance become visible pressure, owned work, and accountable follow-through.
What GRC means in plain English
In Aegis, governance, risk, compliance, and assurance work as one operating loop. Together they tell people what matters, what is drifting, and what must happen next.
- Governance sets the rule of the road: who owns the issue, what standard applies, and when review or escalation is due.
- Risk records the exposure: how serious it is, what controls exist, and whether the current response is still acceptable.
- Compliance shows whether the organisation is actually meeting the obligation, not just saying that it is.
- Audit and assurance test whether the visible response is real, timely, and backed by evidence.
How Aegis turns GRC into work
Aegis turns what would otherwise live in decks, trackers, and side conversations into working surfaces. The point is not to store information. The point is to surface pressure, open the right record, and move the next decision.
- Dashboards show pressure: outside-appetite risk, weak controls, policy debt, high-risk gaps, findings, and overdue remediation.
- My Work is the queue of reviews, decisions, approvals, remediation steps, and escalations that already need attention.
- Registers and workspaces are where you inspect the record, confirm ownership, fix traceability, and decide what happens next.
- Actions, findings, escalations, and work items keep follow-through visible so leadership can see whether the response is moving or stalling.
Why users do what they do in Aegis
Every action in Aegis should answer a practical question: what is rising, who owns it, what happens next, and how will we know the response worked?
- Review risks early because unmanaged exposure becomes leadership pressure later, when it is harder to contain.
- Check controls because policy only matters when it changes how work is actually done.
- Keep policy review current because stale governance content produces weak controls and weaker decisions.
- Track findings, actions, and remediation because acknowledgement is not the same as closure.
The operating loop inside Aegis
The core rhythm in Aegis is simple: read the signal, open the queue, act in the workspace, review the result, then check whether pressure is actually reducing.
- Open your dashboard first and find what looks abnormal, late, weak, or repeated.
- Use My Work to clear the items that already need attention instead of searching the platform blindly.
- Open the relevant workspace and make the next step explicit: review, approve, remediate, escalate, or close.
- Return to the dashboard and queue to confirm pressure is reducing rather than moving somewhere else.
Visual foundations
What is GRC in Aegis
Aegis converts governance structure, risk records, compliance gaps, and audit pressure into visible signals, accountable work, and recorded action.
Governance sets policy, cadence, and ownership
Risk records capture exposure and control linkage
Compliance and audit reveal gaps, findings, and failures
Dashboards surface posture and pressure
My Work routes accountable follow-up
Registers and workspaces hold the governed record
Users review, approve, remediate, or escalate
Signals refresh and posture changes become visible
A user enters Aegis through dashboards, My Work, or a role manual and needs to understand why the platform exists.
- Is the signal informational, or does it require action in a workspace or queue?
- Can the issue be resolved locally, or does it require escalation or review?
- Review governed records
- Approve or escalate work
- Remediate weak controls or findings
Aegis operating model
The current Aegis operating model is backend-first: dashboards aggregate, workspaces compose detail, My Work orchestrates action, and mutations remain inside the owning domain.
Dashboard aggregators build a role-scoped command surface
Reference-data endpoints feed scoped lookups and filters
Workspace endpoints assemble mixed detail views
Domain routes handle updates, approvals, and transitions
My Work consolidates direct, department, and legacy work
Updated posture flows back into dashboards and queues
Aegis pages load role-scoped dashboards, reference data, workspaces, and My Work rather than a single monolithic workflow.
- Should the user go to a workspace now, or act from My Work?
- Is the user working at enterprise, division, or department scope?
- Open a dashboard
- Open a workspace
- Act on routed work
Risk management in Aegis
This diagram reflects the actual risk seam: dashboard or register signal, scoped workspace inspection, lifecycle or linkage improvement, and escalation when the record cannot be responsibly advanced in scope.
Dashboard or register filter highlights a risk needing attention
Reference data supplies owners, taxonomy, categories, and scope
Risk workspace loads detail, timeline, controls, KRIs, incidents, and traceability
Can the record move forward with stronger linkage and review quality?
Update risk, link controls and KRIs, or progress lifecycle
Escalate when exposure cannot be resolved locally or remains outside tolerance
Risk posture refreshes in dashboards, queues, and leadership review
A user opens the risk dashboard or Risk Register, or creates a new risk through app/api/routes/risk_management.py.
- Is the risk ready to progress its lifecycle state?
- Can the issue be resolved in scope, or should it be escalated?
- Improve traceability
- Advance lifecycle state
- Link controls and KRIs
Policy -> Control -> Risk -> Issue/Finding -> Action
This is a code-grounded operating abstraction. The relationships exist across governance, risk, compliance, and audit today, but the traceability path is still partly transitional rather than one perfectly unified runtime engine.
Policy defines expectation, cadence, and ownership
Control implements or evidences the policy
Risk record shows where exposure remains or grows
Incident, failed control test, or audit finding reveals breakdown
Corrective action or remediation is assigned and tracked
Governance posture improves or the gap is escalated
A user opens governance policy or control workspaces, or assurance and compliance pressure points surface related gaps.
- Is the weakness local to one record, or does it reveal a broader governance pattern?
- Does the issue require remediation, escalation, or assurance follow-up?
- Strengthen traceability
- Revisit policy or control ownership
- Launch remediation or corrective action
Dashboard -> My Work -> Action loop
The current work loop is accurate but transitional: canonical work items exist, while legacy assignments and derived workload still fill gaps where projection coverage is incomplete.
Dashboard highlights abnormal pressure and action links
My Work merges effective, legacy, and derived assignments
User opens the underlying workspace or governed record
Approve, remediate, escalate, or defer with reason
Work item becomes completed, overdue, or escalated
Updated status returns to the dashboard signal loop
A user sees posture pressure on a dashboard or opens My Work directly.
- Is there already a work item, or is the user acting from a dashboard signal?
- Is work direct, department-scoped, delegated, or part of an approval chain?
- Process queued work
- Escalate overdue items
- Complete approvals or remediation