> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/solutions-and-use-cases/prove-your-security-posture.md).

# Evidence for a Security Audit

Answer "prove it" for an auditor, customer, or board — posture, SLO attainment, license compliance, SBOMs, and a change log, pulled from live data.

Sooner or later someone asks you to *prove* your security program works — a SOC 2 auditor, a security-conscious customer, or your own board. The usual scramble is a week of screenshots and spreadsheets that are stale before the meeting. Because Heeler already holds posture, deadlines, licenses, dependency inventory, and a change log as live data, you can assemble a coherent evidence pack on demand instead. This use case shows what to pull and where it comes from.

{% hint style="info" %}
**For:** security leadership and GRC. **Prerequisites:** the program running — findings prioritized, SLOs set, ownership mapped. The more of the [SLO-driven program](/mrecEO40m5D6bt7Pq5pE/solutions-and-use-cases/run-an-slo-driven-appsec-program.md) you have in place, the stronger the evidence.
{% endhint %}

## What you can show

<table><thead><tr><th width="260">Question an auditor asks</th><th>What you show, and from where</th></tr></thead><tbody><tr><td>"What's your risk posture, and is it improving?"</td><td>Portfolio posture and trend over time from <a href="/mrecEO40m5D6bt7Pq5pE/operate/dashboards.md">Dashboards</a>.</td></tr><tr><td>"Do you fix issues within a defined time?"</td><td><a href="/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/service-level-objectives.md">SLO</a> attainment and overdue trend — evidence of a deadline policy that's actually met.</td></tr><tr><td>"How do you control open-source licenses?"</td><td>Your allow/deny <a href="/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/license-policy.md">License Policy</a> and any violations.</td></tr><tr><td>"What's in this application?"</td><td>A CycloneDX <a href="/mrecEO40m5D6bt7Pq5pE/catalog/sbom.md">SBOM</a> for the repository, service, or deployment in scope.</td></tr><tr><td>"Who changed your security configuration, and when?"</td><td>The <a href="/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/audit-log.md">Audit Log</a> — every configuration and policy change, with user and timestamp.</td></tr></tbody></table>

## Walk through it

{% stepper %}
{% step %}

### Pull posture and trend

Start with [Dashboards](/mrecEO40m5D6bt7Pq5pE/operate/dashboards.md): current risk posture across the portfolio and how it's trended. This is your headline — "here's where we are, and here's the direction."
{% endstep %}

{% step %}

### Show that deadlines are met

Show [SLO](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/service-level-objectives.md) attainment: the policy (Urgent/Plan/Defer windows) and the proportion of findings resolved within them. A defined-and-met remediation timeline is exactly what a framework like SOC 2 looks for.
{% endstep %}

{% step %}

### Demonstrate license control

Point to your [License Policy](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/license-policy.md) — which licenses are allowed or denied — and that violations surface as findings and get gated at the PR.
{% endstep %}

{% step %}

### Produce SBOMs for the in-scope apps

Generate a CycloneDX [SBOM](/mrecEO40m5D6bt7Pq5pE/catalog/sbom.md) for each application in scope, on demand, grounded in the live dependency inventory rather than a hand-maintained list.
{% endstep %}

{% step %}

### Cite the change log for accountability

Use the [Audit Log](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/audit-log.md) to answer change-control questions: who modified a policy, connection, or role, and when — the accountability record auditors expect.
{% endstep %}
{% endstepper %}

## The outcome

Instead of a manual evidence scramble, you assemble a current, defensible pack — posture, SLO attainment, license control, SBOMs, and a change log — straight from live data, and repeat it any time it's asked for.

## Validate success

* You can produce every artifact above **on demand**, reflecting today's state.
* SLO attainment and posture trend are backed by data, not assertions.
* An SBOM exists for each in-scope application.

## Where to go next

* [Run an SLO-driven AppSec program](/mrecEO40m5D6bt7Pq5pE/solutions-and-use-cases/run-an-slo-driven-appsec-program.md) — the program that produces this evidence.
* [Dashboards](/mrecEO40m5D6bt7Pq5pE/operate/dashboards.md) · [SBOM](/mrecEO40m5D6bt7Pq5pE/catalog/sbom.md) · [Audit Log](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/audit-log.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/solutions-and-use-cases/prove-your-security-posture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.