The Compliance Report

Step 1: Review the compliance report template

Open materials/compliance-report-template.md. The template has six sections required by Directive 2026/CS-04: Executive Summary, Assessment Scope, Methodology, Findings, Continuous Monitoring Capability, and Recommendations. A Technical Appendix follows with subsections for Detection Rules Deployed, CIS Benchmark Assessment, and Remediation Evidence.

The audience for this report is the Ministry of Information and Communications directive committee. They are not security professionals. The guidance notes in the template make this explicit: "Write for the directive committee" and "explain in language the committee understands." Technical precision matters in the appendix. Plain language matters in every other section.

Step 2: Write the findings section

Direct AI to produce the findings section from the documented work across Units 2 through 6.

AI orders findings by discovery sequence -- the SQL injection first because you found it first, then the XSS, then the API bypass. The directive committee does not care about discovery order. They care about risk. Reorder the findings by severity: the API authentication bypass (Critical) first because it connects all three portals into a single attack surface, the SQL injection (High) next because it exposes tourist passport data, then the remaining findings in descending priority.

For each finding, the language must be appropriate for the audience. "SQL injection in the search endpoint via string concatenation in the query builder" is for the technical appendix. "The Tourism Services Portal's search feature could be manipulated to extract tourist passport numbers and travel records directly from the database" is for the directive committee.

AI translates technical findings to plain language but tends to either oversimplify (losing the severity signal) or under-translate (leaving unexplained jargon). Read each finding and judge whether the committee would understand both what happened and why it matters.

Step 3: Document the continuous monitoring capability

This is the most important section for compliance purposes. The directive required "continuous monitoring capability." The committee needs to understand what the monitoring systems detect, what they do not, and what operational maintenance is required.

Explain both monitoring systems in terms the committee can act on. Loki collects application-level activity -- it records what users do on the portals. Wazuh monitors system-level events -- it detects when something happens inside the servers that the applications do not report. Together, they provide visibility that neither system achieves alone.

Describe the detection rules deployed across both platforms. Explain that the rules fire when someone attempts specific attack patterns -- even after the underlying vulnerabilities have been fixed. The committee should understand that monitoring continues to protect the portals even after the assessment ends.

Be honest about what the monitoring does not cover. If there are categories of threats the current detection rules do not address, state them. The committee will trust a report that acknowledges limitations more than one that implies complete coverage.

Step 4: Write the recommendations section

The recommendations section covers four areas:

• Remaining findings -- any findings not yet remediated, with recommended timelines. Not everything needs to be fixed immediately. Priority ordering aligns with the findings section.
• Operational recommendations -- maintaining the SIEM requires ongoing work. Someone needs to review alerts, update detection rules as threats evolve, and maintain the agent configurations. The committee needs to understand this is not a one-time deployment.
• Staffing implications -- the monitoring systems generate alerts that require human review. The BTC has 25 staff. The recommendation should be realistic about the level of effort needed.
• Visa portal -- reference the scope creep management from Unit 6. Recommend a separate assessment for the Ministry of Foreign Affairs portal and note integration points for future planning. This demonstrates professional scope management in the report itself.

Step 5: Update the engagement memory

Open your CLAUDE.md engagement memory file. Update it with the final state of the assessment:

• Findings discovered and their remediation status
• Detection rules deployed and their platform-specific notes
• CIS Benchmark items assessed and their outcomes
• Scope decisions (including the visa portal exclusion and rationale)

This is a professional close-out practice. The engagement memory file now serves the next person who works on the BTC's security -- whether that is you or someone else. The file carries the project history forward.

Open materials/CLAUDE.md to confirm the original project governance file still reflects the engagement accurately. The work breakdown and verification targets should align with what was actually accomplished.

Step 6: Push and present

Push the final repository to GitHub with a clear README describing the engagement, the monitoring infrastructure deployed, and the compliance report deliverable.

git add -A

git commit -m "BTC security assessment: compliance report and monitoring infrastructure"

git push origin main

Open the living client interface and present the compliance report to Tshering. She will review it for the directive committee. If the language is too technical, she will ask for clarification -- the committee members are not security professionals and she will not forward a report they cannot understand. If the continuous monitoring section describes SIEM architecture in technical terms, she will push back.

She will be satisfied if the report demonstrates three things: continuous monitoring is in place, critical findings have been addressed, and remaining items have clear timelines. She will ask about the visa portal recommendation -- your scope management from Unit 6 pays off here because you already have a clear answer documented.