Vulnerability Management for ISO 27001 and SOC 2: Scanning, Patching and Evidence
Vulnerability management is the control where organisations most often have the tooling and still fail the audit. The scanner runs weekly. The reports are in a folder. Nobody can show that anything was fixed, by when, or why the 400 open findings are acceptable.
Both ISO 27001 and SOC 2 are less interested in whether you scan than in whether you have a closed loop: find, assess, prioritise, remediate, verify, and evidence each step. That loop is the control. This article covers what the frameworks require, how it lines up with the ASD Essential Eight, and what an auditor will ask for.
What ISO 27001 requires
ISO 27001:2022 covers this in a cluster of Annex A controls:
- A.8.8 Management of technical vulnerabilities. Information about technical vulnerabilities in information systems in use is obtained, exposure is evaluated, and appropriate measures are taken.
- A.8.9 Configuration management. Configurations, including security configurations, of hardware, software, services and networks are established, documented, implemented, monitored and reviewed.
- A.8.19 Installation of software on operational systems. Procedures are implemented to securely manage software installation.
- A.8.29 Security testing in development and acceptance. Testing processes are defined and implemented in the development lifecycle.
- A.8.32 Change management. Changes are subject to change management procedures.
- A.5.7 Threat intelligence feeds the front of the loop: information relating to threats is collected and analysed.
A.8.8 has three verbs, and organisations reliably do the first and skip the second. “Exposure is evaluated” means a CVSS score alone is not an answer. A critical vulnerability on an internet-facing system with a public exploit is not the same risk as the same CVE on an internal system behind MFA with no network path to it. The framework expects you to make and record that judgement.
A.8.29 is worth noting for software companies. If you build a product, security testing in the development lifecycle is in scope, which means dependency scanning, static analysis and pre-release testing, not just infrastructure scanning in production.
What SOC 2 requires
- CC7.1. Detection and monitoring procedures are used to identify changes to configurations that introduce new vulnerabilities, and susceptibility to newly discovered vulnerabilities.
- CC8.1. Changes to infrastructure, data, software and procedures are authorised, designed, developed, tested and approved before implementation. Patching is a change, and auditors test it as one.
- CC4.1. Evaluations are performed to determine whether controls are operating. This is where penetration testing commonly sits in a SOC 2 report.
- CC3.2 and CC3.4. Risk identification and assessment of changes, which is where your exposure evaluation gets its home.
The thing that catches people in a Type 2 is CC8.1. Emergency patching that bypasses your change process creates a documented exception every time, and an exception with no record is a finding. Define an emergency path inside the process rather than outside it, with retrospective approval and a time limit.
The overlap
| What you build | ISO 27001 | SOC 2 |
|---|---|---|
| Asset inventory | A.5.9 | CC6.1, CC7.1 |
| Authenticated vulnerability scanning | A.8.8 | CC7.1 |
| Risk-based prioritisation with SLAs | A.8.8, A.5.7 | CC3.2, CC7.1 |
| Patch and remediation process | A.8.8, A.8.32 | CC8.1 |
| Secure configuration baselines | A.8.9 | CC7.1 |
| Penetration testing | A.8.29, A.8.8 | CC4.1 |
| Exception and risk acceptance register | A.8.8 | CC3.2 |
Everything depends on the asset inventory
You cannot evidence coverage without knowing what exists. An auditor’s first question after “show me your scan results” is “is that everything”, and the only credible answer is a comparison against an inventory maintained independently of the scanner.
For cloud environments, pull the inventory from the cloud provider’s own API rather than maintaining it by hand, because it will be right and it will be current. For endpoints, your device management platform is the source of truth. Reconcile the two against your scanner’s coverage quarterly and keep the reconciliation, because that document answers the coverage question before it is asked.
Shadow IT is the gap here. A SaaS application nobody told IT about is both an unscanned asset and, usually, an unmanaged access path.
Define remediation SLAs and then hold to them
This is the part that converts a scanning exercise into a control. Set target timeframes by severity and by exposure, write them into the policy, and measure against them.
A defensible starting position for most Australian mid-market organisations:
- Critical, internet-facing, exploit available: 48 hours
- Critical, internet-facing: 2 weeks
- High, internet-facing: 2 weeks
- Critical and high, internal: 1 month
- Medium: 3 months
- Low: next scheduled maintenance, or formally accepted
Two points on this. First, the numbers must be ones you can actually meet, because an SLA you breach every month is worse evidence than a longer SLA you meet. Set it where you can hold it and tighten it later. Second, align it with the Essential Eight if you report against that too, so you are not maintaining two sets of targets.
Anything you will not fix goes in a risk acceptance register with a named owner, a reason, a compensating control and a review date. Both frameworks accept risk acceptance. Neither accepts silence.
How this maps to the Essential Eight
Two of the eight mitigation strategies are patching: patch applications and patch operating systems. The ASD maturity model sets its own timeframes, with the tightest applying to internet-facing services where a working exploit exists, and it also expects vulnerability scanning at a defined frequency, more often for internet-facing assets than internal ones.
If you are pursuing ISO 27001 or SOC 2 and reporting Essential Eight maturity, build one vulnerability management process that meets the strictest of the applicable timeframes and report it against all three frameworks. The ACSC revises the maturity model periodically, so check the current publication rather than working from a maturity assessment done two years ago.
Regular penetration testing also supports A.8.29 and CC4.1 while giving you something scanning cannot: validation of whether the vulnerabilities that remain are actually exploitable in your environment, and whether chained low-severity issues add up to something serious. Scanners find known CVEs. They do not find broken authorisation logic in your own application.
What auditors ask to see
- The vulnerability management policy, including the SLAs.
- The asset inventory, and a reconciliation showing scan coverage against it.
- Scan configuration. Authenticated or unauthenticated, frequency, scope. Unauthenticated-only scanning understates your exposure and auditors know it.
- A trend over the observation window, not one point-in-time report. Open findings by severity over time tells the auditor whether the loop closes.
- A sample traced end to end. Pick a critical finding, show the detection date, the assessment, the change record, the remediation and the verification scan. This single artefact does more than any policy.
- Evidence against the SLAs, including breaches and why.
- The risk acceptance register, with current review dates.
- The most recent penetration test report and the remediation evidence. A report with no remediation record is a finding in itself, and it is the most common one we see on client-supplied test reports.
- Dependency and container scanning, if you build software.
The failure modes we see most
Scanning without closing the loop. Reports accumulate, findings do not get owners, and the open count only goes up. Assign findings to people with due dates in whatever tracker your engineers already use, not in a spreadsheet beside the reports.
Unauthenticated scanning only. It misses most of what is actually on the host. Credentialed scanning or an agent gives you a real picture.
No verification scan. “Patched” with no evidence the finding is gone. Re-scan and keep the result.
Emergency patching outside change control. Build the emergency path into the process.
A penetration test with no remediation trail. Organisations buy the test for the certificate and never work the findings. Both frameworks look at what you did about it, and retesting the fixed items is what demonstrates the loop closed.
Third party and dependency blind spots. Your own code is clean and a transitive dependency three levels down is not. Dependency scanning in CI, with a policy for what blocks a release.
End-of-life software with no plan. An unsupported operating system cannot be patched, so it needs a documented migration plan and a compensating control. “It still works” is not a risk treatment.
Australian considerations
Beyond the Essential Eight mapping above, the practical driver is breach exposure. An unpatched internet-facing service with a known exploit is the most common initial access vector we see in incident work, and if it leads to unauthorised access to personal information you are into Notifiable Data Breaches territory under the Privacy Act, with a 30 day assessment window.
APRA-regulated entities have specific obligations under CPS 234 around vulnerability and threat management that sit alongside, not instead of, the above.
Where to start
Get the inventory right. Turn on authenticated scanning across all of it. Set SLAs you can meet. Route findings into the tracker your engineers already live in, with owners and dates. Re-scan to verify. Put what you will not fix in a register with a review date. Then book a penetration test to find the things a scanner cannot.
Our CERTIFY compliance package covers the vulnerability management control design and evidence set for ISO 27001 and SOC 2, and we deliver the penetration testing that supports A.8.29 and CC4.1. If you have scan results you are not sure how to act on, get in touch and we will go through them with you.
Siege Cyber’s CERTIFY packages take Australian businesses from gap analysis to certification with a fixed scope and a fixed price, for both ISO 27001 and SOC 2. Get a Fixed-Price Quote.