Security & Trust

01 Data isolation

Lobbero is organised around the building. A concierge working the desk at one property cannot see another property's residents, visitors or parcels — the data is separated per building, and it becomes reachable to a person only through an explicit access grant.

The separation is enforced in the database itself, not only in the application, so a mistake in application code cannot quietly cross a building boundary.

For organisations running several properties, buildings can be grouped into portfolios for reporting. Grouping never widens who can see what: access is always resolved from the grants a person holds, not from how buildings are filed.

02 Access & authentication

Roles and grants

Access is role-based and least-privilege. We separate what you assigned from what a person can actually reach, and the resolved view is recomputed whenever a grant changes — so an administrator can always see the real consequence of a change. A grant can give day-to-day desk access or, separately, administrative control over a building's structure; only an owner can grant administrative control. Revoking a grant takes effect immediately, and a grant with an end date stops working when it expires.

Sign-in

Passwords are stored hashed, using a current, deliberately slow password-hashing function — never in plain text, and never recoverable by us. Two-step sign-in is available on every account, with recovery codes for a lost device, and an owner can reset it for someone who has lost both. Sign-in, password reset and the second step are all rate-limited, and repeated failures lock an account temporarily.

Sessions

Sessions are short-lived and renewed in the background, so a stolen session has a narrow window rather than an open one. Signing out everywhere is immediate and ends every session on the account. People can see the devices signed in to their account and end any of them.

Our own access

Support access to a customer's account is time-limited and audited: a grant stops working when it expires, and a record of it remains in the audit trail. Lobbero staff working in our internal console hold a separate, short-lived elevation that is logged the same way, and that console is read-only — it cannot change a customer's records.

03 Encryption

Data is encrypted in transit between your browser or device and Lobbero, and between our own services — using modern, industry-standard protocols, with obsolete versions refused.

The personal identifiers a front desk records — names, email addresses, telephone numbers — are also encrypted at rest, with a strong authenticated cipher, so that reading the stored data does not hand over an address list. Keys are held separately from the data they protect. If encrypting an identifier ever fails, the write is refused outright rather than falling back to storing it in the clear.

04 Lobbero IQ & AI

We do not use customer data to train or fine-tune any model — ours or a vendor's. That is a contractual commitment in our Data Processing Agreement, not a setting.

Lobbero IQ is decision-support. It summarises and surfaces what is already in your log, and a member of your staff acts on it; it makes no automated decision about any person. Every answer cites the entries behind it, and it tells you when the entries it searched contain nothing rather than guessing.

The underlying model is operated by a third-party provider under a data-processing agreement that includes Standard Contractual Clauses and an explicit no-training commitment. Log text is sent at the moment a question is asked, and a photographed document at the moment it is scanned — not in bulk, and not on a schedule. The current provider is named in our Privacy Policy.

05 Data minimisation

The least sensitive system is the one that never held the data.

• Identity documents are not stored. When an ID is scanned at the desk we read the name and discard the image — "extract and discard". The photograph is never written to storage.
• Parcel tracking numbers are stored masked.
• Email addresses are masked in our logs, so operating the service does not accumulate a plaintext copy of every address it has ever handled.
• Each record type has a defined retention period, configurable by the customer, with a floor below which it cannot be set. When a record is removed, every copy of it goes too — earlier versions, search indexes and scan data.
• A parcel still on the shelf is never removed by retention.

06 Audit trail & record integrity

The audit trail is append-only: the application can add to it, and cannot alter or delete what is already there. Deleting a visit or an activity is itself recorded, without personal data in the audit entry — so a removal leaves a trace even though the record is gone.

Entries carry who authored them and keep their earlier versions, so a corrected record shows that it was corrected. A failed audit write cannot silently undo the change it was recording.

07 Hosting & resilience

Lobbero runs on a major cloud provider, and service data is hosted in the European Union. The application and the database are separated, and the connection between them is encrypted and pinned, so it cannot be redirected to a different database.

Backups are taken regularly and verified — a backup nobody has restored is a hope, not a backup — and are kept for a defined period. When a customer's contract ends we delete or return their data and can certify that we have done so; see the DPA.

Data residency, our backup and disaster-recovery posture, and the specifics behind any of the above are available to customers and prospects on request at security@lobbero.com.

08 Vulnerability & change management

• Dependencies are monitored for known vulnerabilities, and a release is blocked rather than shipped while a critical advisory is open.
• Changes go through code review and automated checks before release, and database changes are rehearsed against a restored copy of production before they are applied to it.
• We review our own security posture on an ongoing basis, including adversarial review before significant releases.

We are happy to discuss our testing and assurance programme, and its current state, with customers and prospects under NDA.

09 Incident & breach response

We maintain an incident-response procedure that identifies, contains and investigates security events. If a personal-data breach occurs, we notify the relevant supervisory authority within 72 hours where the GDPR requires it (Article 33), notify affected customers without undue delay, and meet applicable US state breach-notification obligations. Our Data Processing Agreement commits us to notifying customers within 48 hours, so that a controller can meet its own 72-hour deadline with time to spare.

10 Sub-processors

We use a small set of vetted service providers, each under a contract limiting them to our instructions and, where relevant, Standard Contractual Clauses. The current list — who they are, what each receives and where — is maintained in our Privacy Policy, and we notify customers before adding a new one, as the DPA requires.

There is no analytics, advertising or error-tracking provider in the product or on this website.

11 Compliance

Lobbero is built to support our customers' obligations under the GDPR and UK GDPR, and the CCPA/CPRA and comparable US state privacy laws. Concretely: a Data Processing Agreement for every customer, a maintained record of processing activities, per-record-type retention, tooling that lets an owner find, export and erase an individual across their records, and deletion or return of data when a contract ends.

We will share our current certification and assurance status, and complete your security questionnaire, on request at security@lobbero.com. We will not imply a certification we do not hold.

12 Report a vulnerability

If you believe you have found a security issue, please tell us at security@lobbero.com before disclosing it publicly, and give us reasonable time to fix it. We will acknowledge your report, keep you updated, and will not pursue good-faith security research conducted under this policy. Please avoid accessing other people's data, degrading the service, or running automated scans that could affect availability.

Our contact details are also published at /.well-known/security.txt.