Give raw vulnerability reports to the people who fix them and the people who oversee that work, and give everyone else summaries. A detailed list of unpatched flaws in named systems is useful to an attacker, so treat it as sensitive data with role-based access and a record of who looked.
Why reports are sensitive
A scan export names systems, versions and weaknesses. If it leaks, it saves an attacker the reconnaissance step. Penetration test reports are even more specific, since they describe working attack paths.
NIST's least privilege control allows only the accesses necessary to accomplish assigned tasks. New York's financial services rule asks covered entities to limit user access privileges to what is necessary to perform the user's job, and to review all user access privileges at least annually. Those principles apply to your security tooling as much as to production systems.
A role-based view
| Role | Needs | Suggested access |
|---|---|---|
| Engineers | Findings for the services they own | Their own projects, full detail |
| Security team | All findings, triage and exceptions | Full read, scoped write |
| System owners | Findings and deadlines for their systems | Their systems, full detail |
| Executives and committees | Trends and overdue counts | Summaries only |
| Auditors | Samples and populations | Time-limited read, or exports |
| Vendors and contractors | Findings for work they perform | Scoped to the engagement |
| Sales and customer success | Statement of posture | No raw findings |
Practical controls
- Use groups tied to project ownership, so access follows the team.
- Remove access on role change and departure. Review it on a schedule, at least annually.
- Restrict export rights. Most users need to view, few need to download.
- Log views and exports of the full list, and review unusual activity.
- Encrypt stored exports and set expiry on shared links.
- Do not paste findings into open chat channels or public tickets.
Sharing outward
Customers and auditors ask for evidence. Give them what answers the question, such as a summary of open findings by severity and age, a sample trail, or a redacted pen test summary, not the raw list. If a raw report must be shared, use a time-limited secure channel, an agreement on handling and a record of what was sent.
Tickets and trackers
Findings often move into general trackers where many staff have access. Mark vulnerability tickets as restricted, or keep detail in the security tool and put only an ID in the general ticket.
Third parties
Scan tools and platforms process your findings too. When you assess third-party service providers, include how they protect that data. New York's rule asks for due diligence and periodic assessment of providers based on risk, with attention to their access controls and encryption.
Where tooling helps
Safeguard supports policy and access controls on projects and findings, so findings can be scoped by team. Check your own configuration against the role table above and review it regularly.
Quick check
Should developers see findings for services they do not own?
Usually not by default. Grant it when there is a reason, such as a shared library, and review the grant periodically.
Is a summary safe to share widely?
Generally yes if it contains counts and trends without system names or exploit detail. Check it before circulating.
Sources
- NIST SP 800-53 Rev. 5 catalog, AC-6 Least Privilege
- 23 NYCRR 500.7, Access privileges and user management
- 23 NYCRR 500.11, Third party service provider security policy
Last reviewed: 19 October 2026.
