What does edtech vulnerability management need to pass an audit?

An edtech vulnerability management programme that auditors accept has a written policy with severity based deadlines, a complete asset and dependency inventory, regular scanning, a prioritisation rule that includes known exploitation, dated proof of fixes, and approved exceptions. Auditors test whether you did what your own policy says.

What are auditors actually checking?

They rarely judge whether your deadlines are the right ones. They check that you set deadlines, met them, and can show it. Three questions recur: is the scope complete, is the process written and followed, and is there evidence for a sample of items.

For edtech, scope is wider than teams expect: web app, mobile apps, learning platform plugins, integrations with school information systems, cloud infrastructure, and open source dependencies in every repository.

Which reference points are safe to cite?

NIST SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning, published April 2022, defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. It frames patching as preventive maintenance and recommends an enterprise strategy that simplifies and operationalises patching. Citing it in your policy gives the process a recognised basis.

CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation. Binding Operational Directive 22-01 requires US federal agencies to remediate catalog entries within timelines set by CISA, with default timelines of two weeks for CVEs assigned in 2021 or later and six months for earlier ones. It does not bind private companies, but it is a defensible external benchmark: a vulnerability on the catalog moves to the front of your queue.

What does the policy need to say?

Keep it short and specific:

• scope: systems, repositories, containers, third party code
• scan frequency for each class
• severity definitions and the deadline for each
• an escalation rule: known exploited or internet facing issues jump the queue
• roles: who triages, who fixes, who approves exceptions
• exception process with an expiry date
• reporting: what leadership sees and how often

Do not copy deadlines you cannot meet. A 7 day critical deadline you miss half the time produces findings. A 15 day deadline you meet every time passes.

What evidence do you keep?

For each sampled finding, an auditor wants the detection date, the severity and reasoning, the ticket, the owner, the fix or mitigation, the verification (a rescan or test), and the closure date. Keep scan reports with dates, and keep the list of what was in scope at the time.

Constructed example: an auditor samples a critical library vulnerability from March. Your evidence: scan result on March 3, ticket opened March 3 with an owner, pull request merged March 9, rescan clean March 10, closure within your 14 day policy. Another sampled item missed its deadline: it has a signed exception from the engineering lead and the CTO, a compensating control (the vulnerable function was not reachable, with the analysis attached), and an expiry date. That passes.

How do you handle exceptions and false positives?

Record each one: why, who approved, what compensates, when it expires. Reachability evidence, such as showing the vulnerable code path is never called, is a good reason to deprioritise, but write it down. An unrecorded decision looks like an ignored finding.

What breaks programmes in practice?

• Asset inventory that omits a repository or a staging environment
• Scanners that run but nobody reads the output
• Tickets closed without verification
• Policy deadlines that differ from what the tool is configured to enforce
• Exceptions with no expiry

What to do

1. Write the policy with severity deadlines you can meet, citing NIST SP 800-40 Rev. 4 as the process basis.
2. Build the inventory of systems, repositories and dependencies, and review it quarterly.
3. Scan on a schedule and on every pull request for code and dependencies.
4. Add known exploited vulnerabilities as an automatic escalation rule.
5. Track each finding in tickets with owner, dates and verification.
6. Use a signed exception form with compensating controls and expiry.
7. Run a mock audit: sample ten closed findings and check the evidence is complete.

Safeguard's dependency scanning, reachability analysis and policy gates can supply several of these records, and its compliance automation can organise them as evidence. They support your programme; the audit outcome depends on your own processes.

Quick check

Sources

• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, NIST, fetched 18 October 2026
• Known Exploited Vulnerabilities Catalog, CISA, fetched 18 October 2026
• BOD 22-01, CISA, fetched 18 October 2026

Last reviewed: 18 October 2026.