Security

Last updated: March 17, 2026. ComplianceRadar.dev takes the security of your data seriously. This page summarizes how we protect data in transit and at rest, and how we handle the content we process during scans.

The security infrastructure and policies of the ComplianceRadar.dev service are managed by Damir Andrijanic.

Encryption in transit

All access to ComplianceRadar.dev is over HTTPS (TLS). Data exchanged between your browser and our servers, and between our servers and third-party services (e.g. Stripe, Google Gemini API), is encrypted in transit. We use industry-standard TLS configurations and do not serve the application over plain HTTP.

Encryption at rest

Data stored by ComplianceRadar.dev is held in a PostgreSQL database. Database storage is encrypted at rest by our hosting and database provider. Access to the database is restricted to the application and authorized operations only, with appropriate access controls and monitoring.

AI processing boundary (Gemini)

ComplianceRadar uses the Google Gemini API to generate compliance findings. For URL scans, extracted website text is sent for analysis. For architecture uploads, extracted PDF text is sent for analysis. We do not send full account databases or your entire application code by default; however, text you submit or text extracted from scanned sources can be included in AI requests.

Scraped content and retention

For URL scans, we process fetched HTML and extracted text to generate results. Raw fetched HTML is not stored as a permanent report artifact. Structured scan results are stored in our database so reports can be displayed later. These results may include model-generated summaries, observations, and recommendations derived from scanned content.

PDF upload controls and processing lifecycle

For architecture document uploads, we enforce PDF file validation (type/signature/size checks) before processing. Uploaded documents are intended for non-personal technical documentation only. Raw PDF bytes and extracted text are cleared after successful processing. If processing fails or retries are pending, uploaded data may remain temporarily until the job is completed, retried, or marked failed. Structured report outputs are retained for product functionality.

Authentication and access control

User authentication is handled via NextAuth with support for OAuth (e.g. Google) and credentials. Passwords for credential-based accounts are hashed using industry-standard methods. Session and API access are controlled so that users can only access their own scans and account data.

Private-by-default reports

Scan reports are private by default with access controls designed to reduce unauthorized disclosure. If a user chooses to publish or externally share report data, that user is solely responsible for the publication decision and resulting disclosure.

Non-authenticated URL scan reports require a signed, time-limited access token in the results URL for access. Public reports remain accessible only where the user explicitly enables publication.

Architecture document upload reports are restricted to authenticated account access by default.

Cookie controls and consent baseline

We use a deny-by-default cookie posture for non-essential cookies and trackers. Non-essential analytics remain disabled until the user provides explicit consent.

Waitlist double opt-in

Waitlist subscriptions use a double opt-in confirmation flow so a subscription becomes active only after the email holder verifies the request.

Application logging practices

Our logging objective is to minimize personal data in routine logs. Operational and security diagnostics may include limited metadata and error context required to maintain the service. We continuously review logging to reduce unnecessary data exposure.

Enterprise Privacy Mode (planned)

We are designing an Enterprise Privacy Mode for organizations that need stricter controls around AI processing, retention windows, and processor configuration. This section will be updated as those controls become generally available.

Sub-processors and compliance

We use a limited set of sub-processors (Vercel, Supabase, Stripe, Zoho, and Google Gemini API) for hosting, database, payments, transactional emails, and AI analysis. We select providers with strong security and compliance practices and, where required, put in place data processing agreements. For more detail on how we use and protect your personal data, see our Privacy Policy.

Reporting security issues

If you believe you have found a security vulnerability in ComplianceRadar.dev, please contact us responsibly. We will acknowledge and work to address verified issues in a timely manner.

← Back to ComplianceRadar.dev