The Assessment Report

Step 1: Structure the report using the template

Open materials/assessment-report-template.md. The template has three sections: Executive Summary, Compliance Evidence, and Technical Findings.

Each section has a different audience. The executive summary is for Andres -- a general manager who runs a coffee cooperative. The compliance evidence is for the Portland buyer's supply chain compliance team. The technical findings are for the developer in Caracas who will implement the remaining fixes.

The same findings appear in all three sections, but the language, detail, and framing are different. The executive summary says "buyer pricing could be accessed by an outsider." The compliance evidence says "Finding CS-001: SQL Injection (High) -- Export Tracker /search endpoint." The technical findings say "The /search endpoint concatenates user input into a SQL query string without parameterization."

Review the assessment-report-template.md structure. Map each confirmed finding, remediation, and compensating control to all three sections. Each finding needs three descriptions -- one for each audience.

Step 2: Write the executive summary

The executive summary is the section Andres will actually read. It must make sense to someone who runs a coffee cooperative -- not a security professional.

Write it in plain language. No unexplained technical terms. No CVE numbers. No ATT&CK references. When you need to describe a vulnerability, describe what it means for the business: "An outsider could search the export tracking system and retrieve buyer pricing data" is clear. "SQL injection vulnerability in the /search endpoint allows unauthenticated data exfiltration" is not -- even if it is more precise.

Write the executive summary section of the assessment report. Cover: what was assessed (the cooperative's digital infrastructure), what was found (security issues that could expose buyer pricing and farmer data), what was fixed during the assessment, what compensating controls are in place, and what needs to happen next (top three priority recommendations). Use language Andres would use to explain this to his cooperative board.

AI commonly writes executive summaries that are condensed technical reports. "The assessment identified 7 vulnerabilities across 4 CVSS severity levels" is a technical summary dressed in executive clothing. Read what AI produces and rewrite anything that would make Andres stop reading.

Step 3: Write the compliance evidence

The compliance evidence section is designed for the Portland buyer's supply chain compliance team. These are people who review security documentation across many origin partners. They need standardized, structured information.

Write the compliance evidence section. Include: assessment methodology (tools used, approach taken, date range), scope (all systems assessed with their function), findings summary table (Finding ID, Severity, Description, Status: Remediated / Compensating Control / Recommended), and a statement of the cooperative's security posture improvement. Format this as a formal compliance artifact.

The compliance evidence needs to demonstrate that the assessment was methodical -- not a quick scan but a structured engagement with scoping, threat modeling, cross-tool verification, and risk-assessed remediation. The methodology section is where the Portland buyer sees that the cooperative took this seriously.

Step 4: Write the technical findings

The developer in Caracas needs to implement the remaining fixes. The technical findings give them exactly what they need: which file, which line, what the vulnerability is, how to reproduce it, and what the fix looks like.

Write the technical findings section. For each vulnerability, include: a unique finding ID, severity, affected system and endpoint, description of the vulnerability, reproduction steps (exact commands or inputs), evidence (what data was accessed or what behavior was demonstrated), remediation recommendation (with code examples where applicable), compensating controls if the fix is deferred, and rollback procedure reference if the fix is risky.

The technical section references the remediation plan from Unit 7. Where a fix was already implemented, note its status. Where a compensating control is in place, reference the control documentation. Where rollback procedures exist, include them or reference their location.

Step 5: Present the report to Andres

Share the completed report with Andres through the living client interface. He will read the executive summary first -- it is the only section he will read in full.

Andres will ask practical questions: "If we can only do three things before the Portland deadline, what are the three things?" He will ask about the fermentation sensors -- explain what network exposure means for IoT devices in terms he understands. He will ask whether they should talk to the shipping company about the API issue -- tell him yes, and explain what to ask for.

He will thank you and say this is exactly what he needed to show the Portland buyer. That is the test of the report -- not whether every finding is documented, but whether the people who need to act on it can understand what to do.

The report is now the primary deliverable for the engagement. The executive summary, compliance evidence, and technical findings each serve a different reader, but together they tell the complete story: what the cooperative had, what was at risk, what was done about it, and what comes next.