Security & compliance
BMPG B.V. builds software for construction and real estate organisations where project, client and contract data come together. This page explains exactly how the authorisation model works, how we protect data and how to request an access change.
Last updated:
1. The authorisation model in four layers
Our backend uses row level security: access is decided in the database, not in the interface. Every request is evaluated on identity and role before a single row is returned. Everything is closed by default; access exists only where we granted it explicitly and as narrowly as possible.
1. Public layer (visitor)
- Visitors are anonymous and hold no read privileges on any table containing personal data.
- Forms write only through validated server functions; the browser never talks to the database directly to store leads.
- All input is schema-validated (type, length, format) before anything is persisted.
2. Authorization layer (row level security)
- Row level security is enabled on every table; without a matching policy there is no access at all — not even accidentally.
- Roles live in a dedicated roles table, never on a user or profile row, so privileges cannot be escalated through a profile update.
- The role check is a hardened database function with a fixed search path; signed-in users can only query their own role.
3. Admin layer (staff)
- Appointments and intake requests are readable only by a verified administrator.
- Status changes run through server functions that re-check the role on every single call — never in the interface alone.
- Deletion is blocked for all client roles; clean-up happens server-side according to the retention schedule.
4. Server layer (trusted execution)
- Elevated-privilege keys exist server-side only and never reach the browser bundle.
- Confirmation and reminder e-mails, calendar files and integrations run in the server environment behind validation.
- Public endpoints (such as the calendar file) accept only an unguessable token and return exactly one record.
2. Data protection approach
- Data minimisation
- We only request data needed to assess your question and schedule a meeting.
- Encryption
- Traffic runs over TLS; storage and backups are encrypted at the EU-based hosting provider.
- Retention
- Lead data is kept for as long as the contact process requires, then deleted or anonymised.
- Environment separation
- Development, test and production are separated; we never test with production data.
- Need-to-know access
- Only staff with an explicit administrator role can access lead data.
- Logging
- Sign-in attempts and role checks are recorded in an audit log readable by administrators only.
3. Audit logging: who did what, and when
- Every sign-in attempt (successful and failed) with timestamp, e-mail address, IP address and browser.
- Every role check during an admin action, including whether access was granted or denied.
- Every change to roles is recorded by the database itself — even if it were to happen outside the application.
- The audit log is append-only from the application's perspective: no client role can modify or delete entries.
4. Continuous verification on every release
Every release triggers an automated re-scan. It verifies that anonymous visitors cannot read or write any table containing personal data, that the audit log remains closed to client roles, and that managed endpoints leak no data without a valid token. If any check deviates it is immediately visible and resolved before further rollout.
5. Requesting an access change
You can submit the following requests. We respond within five business days and no later than one month, in line with the GDPR. To protect your data we may ask for additional verification.
- Access
- An overview of the data we process about you.
- Rectification
- Correction of inaccurate or incomplete data.
- Erasure
- Deletion of your appointment or intake data.
- Restriction and objection
- Restriction of processing or objection to further use.
- Portability
- Your data in a common, machine-readable format.
- Access change (administrators)
- Granting or revoking an administrator role, recorded in the audit log.
6. Reporting a vulnerability
Think you found a vulnerability? Report it through our contact form with a description and reproduction steps. We confirm receipt, investigate and follow up. We ask that you do not disclose the finding while the investigation is ongoing and that you do not access, alter or delete third-party data.