The Isidore audit outcome

This is the last lesson of the course. By now you can run an Examen scan, read every finding, and translate the result into a remediation plan. The final question is what you hand the client.

The answer is short. The Cathedra results screen is the document. You do not retype the findings into a Word file. You do not build a slide deck. You do not write a 12-page report. The screen exists, it is well-designed, it carries the data accurately, and putting it through a second tool to make it look more like a “report” wastes the client’s time and yours.

What you do add is two pieces of context: a paragraph of executive summary at the top, and a prioritized remediation list at the bottom. Three pages, maximum. PDF export of the result panel as page one and two, summary and remediation pages on either side.

This is how Isidore writes outcomes. It is calm, specific, and short.

The shape of the outcome

In order:

1. Cover (half page) — domain, scan date, technician, overall status, score.
2. Executive summary (one paragraph, ~80–120 words).
3. Cathedra results (the panel from Workbench, exported to PDF).
4. Prioritized remediation list (ordered, with effort and impact noted).
5. Sign-off (technician name, date, next review cadence).

That is it. No appendix of DNS records — Cathedra’s raw DNS panel covers that. No glossary — the client has an engagement contact for terminology questions. No marketing.

Writing the executive summary

The summary is one paragraph. It answers three questions for whoever opens this document at the client side:

1. What did we look at?
2. Where is the domain today?
3. What is the most important thing to act on?

It is written in the Isidore voice. Calm, specific, no hype. No “we strongly recommend.” No “critical vulnerability.” If something is broken, name what is broken. If something is fine, name what is fine.

A real example, for an actual client domain at a posture comparable to isidoregroup.com:

Cathedra scanned isidoregroup.com on 2026-05-13. Email authentication is operating correctly across SPF, DKIM, and DMARC. DMARC is at p=reject with aggregate reporting to a monitored address, which is the end state for this control. Transport security has room to harden — MTA-STS and TLS-RPT are not yet deployed, and Cathedra reports both as opportunities rather than failures. We recommend deploying both in the next maintenance window, alongside CAA records to constrain certificate issuance. No urgent remediation is outstanding.

Note what this paragraph does and does not do.

It names the tool and the date. It names what is working — by control, not by adjective. It names what is not deployed and uses Cathedra’s own framing (opportunities, not failures). It states a recommendation in plain language with a time horizon. It closes by being explicit that nothing is on fire.

It does not say “robust.” It does not say “world-class.” It does not say “we leverage.” It does not say “best practices.” It does not contain an exclamation mark. It is 85 words.

A worse version of the same paragraph — the kind a junior tech writes first time — looks like this:

Cathedra performed a comprehensive scan of isidoregroup.com! Email security looks great overall, with all the core authentication controls in place. However, we did identify several critical items that need immediate attention to ensure your email environment is properly secured against today’s evolving threats. We strongly recommend deploying MTA-STS and TLS-RPT as soon as possible to leverage modern transport security best practices.

Two sentences with exclamation marks. Vague adjectives. “Critical items” that are info-level findings. “Evolving threats” as filler. “Leverage” as a verb. This paragraph is wrong in tone and inflated in claims, and it will read to the client like marketing.

The first version is what you write. Practice it. The voice is harder than the technical content.

The prioritized remediation list

After the Cathedra results, list the items the client needs to act on. Each row is one item. Columns:

1. Priority — 1, 2, 3, etc. Ordered top-to-bottom.
2. Item — one short noun phrase. “Deploy MTA-STS.” “Publish CAA records.”
3. Impact — one sentence on what changes when this is done.
4. Effort — small / medium / large, with hours estimated where useful.
5. Owner — Isidore Service Desk, the client, or both.

A real list for the example above:

#	Item	Impact	Effort	Owner
1	Deploy MTA-STS DNS record and policy file	Enforces TLS validation for inbound SMTP. Pairs with TLS-RPT for observability.	Small (~2 hours)	Isidore Service Desk
2	Deploy TLS-RPT record with reporting address	Surfaces TLS handshake failures into a monitored inbox.	Small (~30 min)	Isidore Service Desk
3	Publish CAA records constraining certificate issuance	Prevents unauthorized CAs from issuing certs for the domain.	Small (~30 min)	Isidore Service Desk
4	Annual posture review	Re-run Cathedra, confirm all controls still operating.	Small (~1 hour)	Isidore Service Desk, May 2027

Three controls and a scheduled re-scan. Total effort under four hours. That is the right shape for a healthy domain.

For a domain in worse condition, the list is longer and the items are larger. A first-engagement audit on a new client with no DMARC at all might have eight items spanning 25–40 hours over an eight-week DMARC ramp. The format is the same; the rows multiply.

What goes into “Owner”

Three values, used consistently across engagements:

• Isidore Service Desk — Isidore is doing the work. Default for any DNS change on a domain we manage.
• Client — the client is doing the work, usually because the change requires action at a system we do not have access to (their CRM, their marketing platform, their HR system).
• Both — Isidore prepares the change, client reviews and approves before deploy, or Isidore configures one side while client configures the other.

Use “Isidore Service Desk” — not “Isidore” or “the team” or “us.” The department vocabulary in the Codex repo is canonical.

The cadence note at the end

Every audit outcome closes with a re-review date. For a domain in healthy posture, annual. For a domain mid-ramp on DMARC, monthly until the ramp completes. For a domain that just had a major DNS change, two weeks post-change.

You name the date specifically:

Next scheduled review: May 2027.

Or:

Next scheduled review: 2026-06-13 (4 weeks post-DMARC ramp completion).

Never “in the future” or “as needed.” Either there is a date or there is no follow-up commitment.

Putting it together

The pattern, every time:

1. Run Cathedra against the client domain.
2. Export the result panel to PDF.
3. Write the executive summary on a blank first page. 80–120 words, Isidore voice. Read it aloud — if you would not say it to the client face to face, it is wrong.
4. Translate findings into a prioritized remediation list on the last page. Order by priority, not by Cathedra category.
5. Add the cadence note. Specific date.
6. Sign your name. Deliver.

The whole document is three or four pages. It takes 30–45 minutes to write once you have done it five or six times. The first one will take you two hours. That is fine.

What you should remember

• The Cathedra results screen is the outcome. Do not retype findings into a different document.
• Wrap the results with two pages: executive summary on top, prioritized remediation on bottom.
• Executive summary: 80–120 words, Isidore voice. Calm, specific, no hype. State posture, name what is working, name the recommendation, state urgency or lack of it.
• Remediation list: priority, item, impact, effort, owner. Ordered, not categorized.
• Close with a specific next-review date. Annual for healthy, shorter for mid-remediation.
• Owner is “Isidore Service Desk,” “Client,” or “Both.” Use the department name from the codex vocabulary.

---

Cathedra alignment: MailDiagnosticsService.php — the Cathedra result is the document; this lesson covers what wraps around it for a client-facing audit outcome