Cavaridge Academy
Setting Up Posture Scans
Module 4 of 5

Triaging findings

Read findings honestly — severity, evidence, suggested action — and decide what to escalate vs document.

Video — pending production
Read the transcript below. Once recording is complete, the video will replace this notice.
--- title: Triaging findings status: draft note: AI-generated first-pass transcript pending video production + SME review. --- Triage is the work that turns AEGIS from a noisy scoreboard into operational signal. This is where the MSP's discipline meets the platform's tooling. ## The four-quadrant frame Every finding lands in one of four quadrants: | | High evidence | Weak evidence | | ----------------- | ---------------- | ------------------------- | | **High severity** | Escalate today | Verify, then escalate | | **Low severity** | Document & batch | Verify, then close-or-doc | Two rules to internalize: - **Severity without evidence is noise.** Don't escalate a "high" finding to a customer if the evidence is shaky — verify first. Customer trust does not survive crying wolf. - **Evidence without severity is documentation.** Catalog it, batch it into the next quarterly review, move on. ## What the finding card shows you Every finding has: - **Severity** (informational / low / medium / high / critical) — derived from the framework mapping + the affected scope. - **Evidence** — links into the source artifacts (a config snapshot, log line, screenshot, ticket), each with timestamp + connector attribution. - **Suggested action** — the platform's recommendation. **Treat as a hint, not gospel.** - **Affected scope** — which assets, users, or systems. - **Framework mapping** — which control families this affects. ## Verification When you need to verify before escalating: 1. Click into evidence — open the source artifact in the original provider. 2. Cross-check with a second source (a manual config check, a separate log query). 3. If verified, escalate with citations. If not, mark as "investigation closed — false positive" with the reason. False positives feed back into the platform's tuning. Document them honestly. ## Accepted-risk attestations Sometimes a finding is real but the customer accepts the risk (legacy app, contractual obligation, compensating control elsewhere). The accepted-risk path: 1. Open the finding. 2. Click "accept risk". 3. Attach evidence (the compensating control, the contract, the business decision). 4. Set an expiry — accepted risks expire by default in 12 months. 5. Have a qualified party sign the attestation. The platform records the acceptance, surfaces it in the SPR, and re-prompts before the expiry. **Acceptance does not delete the finding.** Auditors will see it. That's the point. ## Customer escalation When you escalate to the customer: - Include the finding ID and the evidence links. - Say what action you recommend. - Say what action you'll take if you don't hear back in [N] business days. Use Cavaridge Operations templates for these comms — they pull the finding context automatically and include the right brand chrome. ## Hands-on The **aegis-findings-triage** seed gives you a tenant with 12 sample findings spanning all four quadrants. Triage each: - Decide quadrant. - Verify if needed. - Escalate, document, or accept. Compare your decisions to the seed's reference rationale (visible after you complete the exercise). The differences are usually the useful conversations to have with your senior tech. ## What's next Module 5 covers IAR and SPR — the audit-ready artifacts that make your AEGIS work visible and credible to outside reviewers.
Hands-on sandbox
aegis · seed: aegis-findings-triage · 60 min

Knowledge check

  1. Question 1 · select one
    A high-severity finding with weak evidence should be
  2. Question 2 · select one
    When you mark a finding as accepted-risk, the platform
  3. Question 3 · select all that apply
    Pulse events fired during finding triage include