Trust & Security

Engineered for the
discreet handling of
confidential information.

Alarm codes. Safe combinations. Entry credentials. Guard rotations. The information stored inside Property Portfolio Suite is the kind of detail a household trusts to very few people. The platform is engineered, governed and audited accordingly.

The four pillars

How we hold your data

Four commitments shape every line of code, every database row and every operational decision. They apply to family households and enterprise portfolios alike.

Authenticated encryption at rest

Sensitive fields are encrypted before they are written to disk using AES-256-GCM with a unique 12-byte nonce per value. AES-GCM is an authenticated cipher: tampering with the ciphertext causes decryption to fail, so corruption and confidentiality are detected together.

Mandatory two-factor sign-in, hardware-key step-up for admins

Every sign-in, for every user, on every device, requires a single-use six-digit code delivered to the user's registered email (and to WhatsApp where a phone number is on file). There is no way to turn it off. Administrator accounts go further: a registered WebAuthn / FIDO2 hardware security key (YubiKey or platform authenticator) is required to reveal sensitive credentials. A stolen password alone, even an admin password, cannot unlock alarm codes or safe combinations.

Codes never displayed on screen

Alarm codes, safe combinations and door entry credentials are never rendered in the interface. Each reveal requires a fresh password challenge and a single-use email link that self-destructs ten minutes after issue or on first click, whichever comes first.

Tamper-evident audit log

Every sign-in, code reveal, dossier export and document download is written to a hash-chained audit log. Any retroactive modification or deletion, including by someone with direct database access, breaks the chain at the affected row and is reported by an administrator integrity-check tool.

Sensitive credentials

What happens when someone needs an access code?

A code request follows the same controlled flow whether it is an alarm PIN, a safe combination or a master Wi-Fi password. There are no shortcuts.

  1. 1

    The user signs in with their username, password and a fresh six-digit code delivered to their registered email and, where configured, WhatsApp.

  2. 2

    On the relevant directory entry they click the request icon. The interface never shows the code at any point.

  3. 3

    A modal asks them to re-enter their password. This protects against a casual borrower of an unlocked device.

  4. 4

    On success, a single-use secure link is sent to the user's registered email address. The link is valid for ten minutes and self-destructs on first click.

  5. 5

    The code appears on a dedicated secure-view page in the same signed-in session. Closing the tab or revisiting the link returns nothing.

  6. 6

    The request and the subsequent reveal are both written to the tamper-evident audit log with the actor, IP address, device class and timestamp.

Defence in depth

Protecting against the dominant risk: a compromised account

The brief from senior clients is unambiguous: a stolen admin credential, an insider risk, or a lost device can do more damage than a sophisticated external attack. The platform is engineered with that in mind.

Bulk-export rate limits with alerting

Property dossier PDFs, document downloads and the audit log itself are capped per user per minute and per hour. The audit log being rate-limited is deliberate: an attacker who reached a privileged session cannot quietly exfiltrate the audit trail, because doing so would itself trigger an immediate alert. Once a daily threshold is crossed, administrators receive an alert by email naming the account, the export type, the count and the originating IP.

Emergency property lockout

When a phone or laptop is lost, or a staff member's behaviour gives concern, a single click freezes every sensitive field on the affected property. Code-reveal requests return locked until an administrator re-authenticates and clears the lockdown. Both the lock and the unlock are loud entries in the audit log.

Code-rotation report

When a team member leaves, administrators can generate an immediate list of every credential they have requested or revealed since they joined, so each can be rotated. The report is built from the audit log itself, so there is no separate state to maintain or to fall out of sync.

Hardened HTTP responses

Every API response carries Strict-Transport-Security (two years, preloaded), a strict Content-Security-Policy, X-Frame-Options=DENY, Referrer-Policy=no-referrer and Permissions-Policy denying camera, microphone, geolocation, payment and USB access by default.

HttpOnly cookie session model

Authentication tokens are held in HttpOnly, Secure, SameSite cookies. They cannot be read by JavaScript running in the browser, which neutralises an entire class of cross-site scripting attacks. The session can be presented to our servers but never extracted from the user's device.

Enforced password policy

Passwords are validated against a written policy at registration, password change and password reset: minimum eight characters, mixed case, at least one numeral and at least one symbol. The rule is enforced both in the browser and on the server; weaker passwords are rejected before the account is created.

Operational posture

How the platform runs

Hosting & data residency

The platform runs on ISO-certified cloud infrastructure with logical isolation per estate. Each client estate sits in its own database namespace, and every query is scoped by tenant identifier so two estates can never see one another's records. The most sensitive fields (alarm codes, safe combinations, CCTV credentials) are encrypted at the application layer using AES-256-GCM before they reach the database. The host cannot read them. Only your authenticated session, after a step-up authentication challenge, can decrypt them. Specific data-residency commitments and an executed Data Processing Agreement are confirmed at contract for enterprise client estates.

Role-based access

Permissions are granular. Family members, property managers, view-only collaborators and administrators each see a different scope of information. Sensitive sections can be locked down per role.

Backups & recovery

Database backups are managed by the underlying cloud provider. A documented recovery procedure exists; the schedule for restoration drills, and the resulting recovery-time and recovery-point evidence, will be published once verified.

Incident response

A written incident response process governs investigation, containment and client notification. In the event of a personal-data breach, affected clients are notified within the 72-hour window required by UK GDPR.

Session controls & new-device alerts

Every user can review their active sessions and sign out remote devices. A sign-in from a previously unseen device or a new country triggers an immediate alert by email and, where configured, WhatsApp. Inactive sessions are signed out automatically.

Public surface, no third-party tracking

Nothing inside a client portfolio is visible without authentication. The only public surfaces are the marketing site, the new-client enquiry form and the sign-in routes. Adding any new public surface requires explicit owner approval. The platform carries no advertising networks, no third-party analytics, no marketing-attribution scripts and no behaviour trackers. Strictly necessary cookies only.

Administrator IP allowlists

Administrator accounts can be pinned to a list of approved IP addresses. A sign-in from any other address is refused before the password is even evaluated, and the attempt is recorded in the audit log. Time-boxed travel mode can be granted when an administrator is genuinely on the move; the allowance expires automatically and is logged on both ends.

Multi-stage account approval

No new account becomes active until an administrator approves it. Approval is staged: identity verification, payment confirmation, and a separate go-live gate. A registered user cannot reach client data on registration alone.

Trust evidence

What is in production today

The controls below are live in the platform today. Detailed policy summaries and sub-processor information are available to prospective clients under NDA.

Tamper-evident audit log

Every audit-log entry is sealed into a per-tenant SHA-256 hash chain. An administrator can run an integrity check at any time which walks the chain, recomputes each row's hash and reports any break with the exact row and reason.

AES-256-GCM at rest + TLS 1.2+ in transit

Authenticated AES-256-GCM for every sensitive field at rest. TLS terminated at the platform ingress, supporting TLS 1.3 where the client negotiates it.

Responsible vulnerability disclosure

An open mailbox at security@propertyportfoliosuite.com, a published policy at /trust/vulnerability-disclosure and a /.well-known/security.txt file. Researchers acting in good faith are credited and protected from legal action.

Public sub-processor list

Every third party that processes customer data is listed at /trust/sub-processors with the categories of data it sees. Customers are notified by email at least 30 days before any addition.

UK GDPR compliance

The platform is built to the requirements of UK GDPR, including data subject rights (access, rectification, erasure), lawful processing, sub-processor governance and the 72-hour breach notification obligation.

Mandatory MFA on every account, encrypted vault, sealed audit log

The three highest-impact controls that sit beneath every recognised certification are already in production and visible to every client.

For procurement teams

Security questionnaires, data processing agreements, sub-processor lists and policy summaries are available to prospective clients under NDA. A short conversation will tell us which evidence pack is relevant to you.

Cookie Notice

We use only strictly necessary cookies to keep you signed in and protect your account. No advertising, no tracking, no third-party analytics.

Privacy Policy