Security Posture Assessment — Sample
A worked example of a security assessment written to be acted on — findings ranked by what an attacker would actually reach first, evidence for each, and the controls that were already working.
Markdown. No sign-up, no email.
This is an illustrative example. The organisation, findings and evidence below are invented to show the shape of an assessment that changes something. Copy the structure; your findings will differ.
Most security reports fail in the same way: a list of every deviation from a framework, ordered by the framework's numbering, with no indication of which one an attacker would use. This one is ordered by what an attacker reaches first, and it says what is working, so that the organisation can tell effort from theatre.
Security posture — Q3 2026#
| Scope | Corporate identity, cloud estate, one customer-facing application |
| Period | 14–25 July 2026 |
| Method | Configuration review, identity audit, external surface scan, interviews |
| Out of scope | Physical security, third-party assessment, social engineering |
1. Summary#
| Severity | Count | Meaning |
|---|---|---|
| Critical | 2 | Exploitable now, high impact, fix this week |
| High | 4 | Exploitable with modest effort, or high impact once inside |
| Medium | 7 | Meaningful risk, plan this quarter |
| Low | 9 | Worth fixing, no urgency |
The two critical findings share a cause: access granted for a reason that has ended. That is the theme of this assessment, and it is a process problem, not a tooling one.
2. What is working#
Recorded first, deliberately. An assessment that lists only failures gets read as an attack on the team and gets argued with rather than acted on.
- Phishing-resistant MFA is enforced for all staff. No SMS fallback. This is stronger than most organisations of this size and it removes the single most common intrusion route.
- Production deployment requires review. No individual can push to production alone.
- Backups are tested. A restore was performed in June and it worked — the test itself is rarer than the backup.
- Audit logs are written to a separate account that workload credentials cannot reach.
- Patching is current on internet-facing systems, verified by scan.
3. Critical findings#
C1 — Former contractor accounts remain active#
Evidence. Six accounts belong to contractors whose engagements ended between November 2025 and April 2026. Three retain production database read access. One was used to authenticate 11 days ago; the contractor confirms they no longer work with the organisation and did not initiate it.
Why it is critical. A valid credential requires no exploit. The eleven-day-old authentication is either an unreported handover of credentials or an intrusion already in progress, and neither has been investigated.
Fix. Disable all six today. Investigate the recent authentication as a potential incident. Then the process fix: account deactivation must be triggered by the contract end date, not by a manager remembering.
C2 — A database is reachable from the internet#
Evidence. A management port on a production database accepts connections from any address. Firewall rule temp-debug-access, created 2026-02-19, described as "remove after investigation". Authentication is required and no unauthorised access appears in the logs.
Why it is critical. It is directly reachable, it holds customer data, and the only barrier is a password. The rule has outlived its purpose by five months.
Fix. Remove the rule today. Then the process fix: temporary rules need an expiry date set when they are created, because a rule with "temp" in its name and no expiry is permanent.
4. High findings#
| Finding | Evidence | Fix | |
|---|---|---|---|
| H1 | Standing production access for 14 engineers | Access is permanent, not requested per task | Just-in-time access with approval |
| H2 | Service accounts with unrotated keys | Oldest 3 years; 2 appear in a private repository | Rotate, move to a secret store |
| H3 | No alert on bulk data access | A full customer table export produces no alert | Alert on volume anomaly per identity |
| H4 | Session revocation incomplete | Password reset leaves active sessions valid | Revoke sessions on credential change |
H4 deserves emphasis. During the assessment, a password was reset on a test account and the existing session continued working for the remaining lifetime of the token. Every incident response plan here assumes a password reset ends access. It does not.
5. Medium and low#
Summarised; full detail in the appendix supplied to the team.
Medium (7). Access review is annual rather than quarterly · encryption at rest is not enabled on two older storage accounts · logging coverage gaps in one service · no formal classification of data sensitivity · dependency scanning does not run on one repository · device compliance not checked at authentication for contractors · no expiry monitoring on certificates.
Low (9). Mostly hygiene: unused security groups, verbose error pages on an internal tool, missing headers on a staging host, inconsistent naming that makes review harder than it needs to be.
6. The pattern behind the findings#
Ranked findings are useful; the pattern behind them is more useful.
Access is granted well and removed badly. Onboarding is thorough — MFA enforced, roles assigned, approval recorded. Offboarding depends on someone remembering, and the two critical findings, H1 and two of the medium findings are all the same failure seen from different angles.
The organisation does not need a new tool for this. It needs the end of access to be an event that fires automatically: contract end dates, expiry on temporary rules, per-task access that lapses on its own. Every one of those turns "remembering to remove" into "having to renew", which is the direction that survives a busy month.
7. Recommended sequence#
| Week | Action |
|---|---|
| This week | Disable the six contractor accounts · remove the firewall rule · investigate the 11-day-old authentication |
| Weeks 2–3 | Session revocation on credential change · rotate service account keys · alert on bulk data access |
| This quarter | Just-in-time production access · expiry dates on temporary rules · quarterly access review with data owners |
| Next quarter | Data classification · encryption on the remaining storage · certificate expiry monitoring |
Deliberately not recommended: additional security tooling. Nothing in this assessment was missed because a tool was absent. Every finding was visible in systems already in place.
Notes on using this format#
Order by what an attacker reaches first, not by framework section. A report ordered by control number invites the reader to start at the beginning, which is almost never where the risk is.
Give evidence for every finding. "Access review is inadequate" gets argued with. "Six accounts belonging to former contractors, one authenticated 11 days ago" does not.
Say what is working. It costs a paragraph, it is true, and it is what makes the rest of the document land as help rather than as an accusation.
Name the pattern. Twenty-two findings are a backlog. One sentence — access is granted well and removed badly — is something a leadership team can act on.