Privacy and data handling

Privacy Policy

This page explains how the utility is intended to handle session reports, public CVE intelligence, cache data, analytics considerations and future account-based features.

This is an MVP privacy policy draft. It should be reviewed before public production launch, especially if ads, analytics, user accounts, saved reports or paid services are introduced.

Session-first MVP

Generated reports are session-only in the current version and are not stored as user report history.

Public CVE cache only

The cache is intended for public vulnerability intelligence such as NVD, EPSS and CISA KEV data.

No sensitive inputs required

Users should not enter secrets, private keys, passwords or confidential incident details into public forms.

Detailed privacy policy

Last updated: 2026-05-28

1. Scope of this policy

This Privacy Policy explains how the CVSS Business Risk Prioritizer is intended to handle data in the MVP version. The tool is designed as a public security utility that helps users enrich CVE information, add business context and generate a session-only risk report.

2. Session-only reports

Reports generated by this utility are session-only. They are not intended to be saved as user-specific records in the application database. Users should download or print a report before generating a new one, refreshing the page or closing the browser session.

3. CVE lookup cache

The application may cache public CVE intelligence to improve performance and reduce repeated external lookups. Cached data may include CVE identifiers, descriptions, CVSS metrics, vectors, references, affected product hints, FIRST EPSS data, CISA KEV status and source timestamps. This cache is for public vulnerability intelligence, not private user reports.

4. No classic user accounts in the MVP

The initial version does not require classic user accounts, user profiles or saved report history. Future versions may introduce account-based features such as saved scenarios, report history, organization workspaces or paid services. If that happens, the privacy policy, retention rules and access-control model should be updated before launch.

5. Data users should not enter

Users should not enter secrets, passwords, private keys, confidential incident details, customer names, internal hostnames, private IP addressing plans, sensitive architecture details or regulated personal data unless a future production version explicitly supports and protects that data.

6. External source requests

When a user performs a CVE lookup, the application may query external vulnerability intelligence sources such as NVD, FIRST EPSS and CISA KEV. These requests are used to retrieve public vulnerability data. Source availability, response time and accuracy depend on the upstream providers.

7. Server logs and abuse protection

Production hosting platforms commonly collect technical logs such as request time, route, response status, IP-related metadata, user-agent and error traces. These logs may be used for troubleshooting, abuse prevention, rate limiting, security monitoring and service reliability.

8. Advertising, analytics and cookies

The site may use advertising and analytics tools in the future. Before enabling ads, analytics or tracking cookies, the production deployment should include the required cookie/consent controls and privacy notices for the target market. Sensitive report content should not be intentionally sent to third-party analytics providers.

9. Data retention approach

The MVP retention approach is simple: reports are session-only, while public CVE cache entries may be retained temporarily for performance. If account-based features or saved reports are added later, retention periods, deletion controls and access permissions must be defined clearly.

10. Security measures

The application should use standard web security practices such as HTTPS in production, secret management through the hosting provider, ignored local environment files, rate limiting, careful error handling and avoidance of sensitive client-side secrets. No public utility should rely on obscurity as a security control.

11. Changes to this policy

This policy should be reviewed before public launch and updated whenever the application introduces user accounts, saved reports, payment features, ads, analytics, third-party integrations or new data retention behavior.

Plain-language summary

The MVP should cache public CVE intelligence, not private reports. Reports are generated for the active browser session and should be downloaded by the user. If saved reports, accounts or premium services are added later, privacy, retention and access-control rules must be upgraded before release.