Security and Technical Measures

1. Overview

BESS Map collects business email, name, optional company and role, coarse geographic Internet Protocol (IP) location through product analytics, and (for paying customers) payment-method metadata through Stripe. The controls listed on this page are the safeguards we have in place to keep that data confidential, intact, and available. The page is reviewed at every internal security audit and on any material change to the system.

Last reviewed: 2 June 2026.

This page demonstrates compliance with Article 32 of the General Data Protection Regulation (GDPR), which requires the controller to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The page is honest about what is in place and does not claim certifications we do not hold.

2. Encryption in transit

All traffic to bessmap.com is served over Transport Layer Security version 1.3 (TLS 1.3), the current industry baseline. Certificates are issued and rotated by our hosting provider. HTTP traffic is redirected to HTTPS at the edge.

The HTTP Strict Transport Security (HSTS) response header instructs browsers to use HTTPS only when contacting our domain, with a two-year maximum age and the includeSubDomains directive. The domain is configured for the Chrome HSTS preload list so browsers refuse plain HTTP from the first visit.

3. Encryption at rest

The production database is managed PostgreSQL on Neon. All data at rest is encrypted using Advanced Encryption Standard 256-bit (AES-256). Database backups inherit the same encryption.

Hosting, build artifacts, function logs, and environment variables live with Vercel and are encrypted at rest on Vercel's infrastructure. Transactional email content held by Resend, product analytics events held by PostHog, and payment data held by Stripe are all encrypted at rest by those sub-processors.

4. Authentication

Customers sign in with either email and password or Google.

• Passwords are hashed using bcrypt with a cost factor of 12. We never store plain-text passwords and we never receive plain-text passwords from our payment or email sub-processors.
• Google sign-in uses Open Authorization 2.0 (OAuth 2.0) with the state parameter to prevent cross-site request forgery and a strict redirect Uniform Resource Locator (URL) allow-list.
• Sessions are JSON Web Tokens (JWTs) signed with HMAC using Secure Hash Algorithm 256 (HS256), valid for seven days, and delivered as httpOnly cookies with the Secure and SameSite=Lax attributes.
• The JWT verification step pins the algorithm to HS256 at every call site. This refuses the alg=none attack and the HS256-versus-RS256 key-confusion attack class outright.
• Password-reset tokens are single-use, time-limited, and stored as Secure Hash Algorithm 256 (SHA-256) hashes; the plain token exists only in the email link sent to the customer.

5. Authorization and tier gating

Access controls are enforced at three layers, defence-in-depth:

• Edge-runtime middleware. Runs before any route handler. Checks the session cookie, decodes the role and tier, and enforces the admin-area gate plus the per-feature tier gate.
• Route handler. Each Application Programming Interface (API) route revalidates the session and the per-feature tier server-side before doing any database work.
• Database query layer. Every query that returns user-scoped data filters by the authenticated user identifier. Queries use parameterised statements without exception.

Pro-tier features (site scoring, ranked sites, Portable Document Format (PDF) reports, watchlist, alerts) are covered by this triple check. A failure at one layer is caught by the next.

6. Rate limiting and brute-force protection

The four unauthenticated authentication routes (sign-in, sign-up, forgot-password, reset-password) carry per-IP sliding-window rate limits backed by Upstash Redis. Limits are tuned to permit normal human use while refusing automated credential-stuffing and password-spraying traffic. Exceeded limits return HTTP 429 responses with a plain-text reason and the standard Retry-After header.

7. Content Security Policy and HTTP response headers

Every HTTP response carries six baseline security headers:

• HTTP Strict Transport Security (HSTS): two-year max-age with includeSubDomains, preload-eligible.
• X-Content-Type-Options: nosniff, preventing browsers from second-guessing declared content types.
• X-Frame-Options: DENY, refusing to be loaded inside a frame.
• Referrer-Policy: strict-origin-when-cross-origin, withholding the full path when navigating off-site.
• Permissions-Policy: minimised to the surfaces the product actually uses; camera, microphone, geolocation, and similar capabilities are disabled.
• Cross-Origin-Opener-Policy: same-origin-allow-popups, isolating the browsing context from popups opened by other origins.

On top of those headers the application emits a Content Security Policy (CSP) with a per-request cryptographic nonce on inline scripts, the strict-dynamic source expression for loader-based scripts, and frame-ancestors 'none' to block clickjacking. The CSP is currently in report-only mode while the third-party surface is observed; violations are sent to an internal endpoint and reviewed before the policy is moved to enforcement.

Cross-Origin Resource Sharing (CORS) on the API surface is restricted to an allow-list of our own domains. There is no wildcard fallback.

8. Server-Side Request Forgery prevention

Every outbound HTTP fetch the application makes (for example, when ingesting council planning documents) is routed through a safe-fetch wrapper that enforces:

• HTTPS only; plain HTTP is refused at the wrapper boundary.
• Domain host allow-list per ingestion source.
• Domain Name System (DNS) pre-resolution with rejection of internal IP address ranges, link-local addresses, and loopback.
• Maximum response size, with the connection aborted past the cap.
• Redirect-chain auditing, with each hop revalidated against the allow-list.

This blocks the Server-Side Request Forgery (SSRF) attack class at the wrapper boundary so any code path that takes a URL from configuration or content cannot accidentally talk to the internal network.

9. Logging and audit

Production logs from hosting and function execution are retained for 30 days. Security-relevant events emit structured log lines including a correlation identifier so a single request can be traced from edge through middleware, route handler, and database. Logged events include:

• authentication outcomes (success, failure, lockout);
• tier-gate denials;
• rate-limit hits;
• Stripe webhook deliveries and idempotency outcomes;
• administrative actions in the admin area.

Log lines do not contain personally identifiable information beyond the user identifier and the client IP address. Email addresses, payment information, and free-text user content are not written to structured logs.

10. Sub-processors

The third-party services below process BESS Map customer data on our instructions. Each is bound by written contract to apply appropriate technical and organisational measures and to assist us with our GDPR obligations. International transfers rely on the European Commission's Standard Contractual Clauses (SCCs) or, where applicable, the EU-US Data Privacy Framework certification of the recipient.

• Vercel Inc. (United States) - hosting and edge delivery. Production traffic is served from the Dublin region. Standard Contractual Clauses signed.
• Neon Database Inc. (United States) - managed PostgreSQL database. Standard Contractual Clauses signed.
• Stripe Payments Europe, Ltd. (Ireland) - payment processing for paid subscriptions. Data Processing Addendum signed; SCCs cover onward transfers to Stripe's United States affiliates.
• Resend Inc. (United States) - transactional and opt-in marketing email delivery. Standard Contractual Clauses signed.
• PostHog Inc. (European Union region, ingest via eu.i.posthog.com) - product analytics and session replay. Data Processing Addendum signed. Data is held in the European Union region.
• Anthropic PBC (United States) - structured extraction API for council planning documents. Used only on already-public council planning documents. No customer personally identifiable information is sent to this service.
• Voyage AI Inc. (United States) - text embeddings for planning-document clustering. Same scope: public planning documents only. No customer personally identifiable information is sent.

This list is current as of the last-reviewed date at the top of the page. A new sub-processor is added only after the data-protection impact has been reviewed and the contract has been signed.

11. Data retention

• Account data is retained for as long as the account is active.
• Inactive accounts are retained for 24 months from the last sign-in, then anonymised.
• Demo-form submissions are retained for 24 months.
• PostHog session replays are retained for 30 days, then deleted by PostHog defaults.
• Production logs are retained for 30 days.
• Password-reset tokens are retained only until used or expired (a window measured in hours).
• Tax and billing records are retained for the periods required by Irish tax and company law (currently six years from the end of the accounting period).

12. Data subject rights

Customers have the rights of access, rectification, erasure, restriction, portability, objection, and withdrawal of consent set out in Chapter 3 of the GDPR. The Privacy Policy describes how each right is exercised, including the self-service data export and self-service account deletion available in the customer's settings.

For any rights request, email hello@bessmap.com. We respond within one calendar month.

13. Breach notification

If a personal data breach is likely to result in a risk to the rights and freedoms of data subjects, Release Guard Labs Limited will notify the Irish Data Protection Commission within 72 hours of becoming aware, in accordance with Article 33 of the GDPR. Where the breach is likely to result in a high risk to those rights and freedoms, affected data subjects will be notified directly without undue delay, in accordance with Article 34.

We maintain an internal incident-response runbook covering detection, containment, eradication, recovery, notification, and post-incident review. The runbook is reviewed at the same cadence as this page.

14. Security audit cadence

Release Guard Labs Limited performs a full internal security audit at least once per year, with a lighter headline-checks audit each quarter. The June 2026 audit produced this page and the underlying patches. The next scheduled full audit is June 2027.

Each audit covers dependency vulnerabilities, authentication and session handling, authorisation gates, rate-limit configuration, security headers, outbound-fetch posture, logging completeness, sub-processor inventory, retention compliance, and incident-response readiness.

15. Contact for security questions

For any security question, vulnerability report, or security due-diligence query, email hello@bessmap.com with the subject line "Security inquiry". We acknowledge within five business days. Responsible-disclosure reports are welcome; we do not pursue legal action against good-faith researchers who follow standard coordinated-disclosure practice.

16. Last updated

This Security and Technical Measures page was last reviewed on 2 June 2026. Material changes are dated at the top of the page and announced through the same channel as Privacy Policy and Terms of Service changes.