Security

1 · Our approach

Mortartec processes sensitive broker and applicant data — income figures, bank statements, credit references and case files. Security is not a feature we bolt on at the end; it is part of how the platform is designed and operated.

This page describes the technical and organisational measures we apply to protect that data. It is intended for broker principals, compliance officers and IT teams evaluating Mortartec. For how we handle personal data specifically, see our Privacy Policy.

Mortartec Ltd (Company No. 17009028) is registered in England and Wales. Platform infrastructure is hosted exclusively in the United Kingdom to support data residency expectations common in UK mortgage origination.

2 · Infrastructure & data residency

Mortartec runs on UK-based cloud infrastructure (AWS). Production workloads, primary databases and file storage for case documents are kept within UK regions unless a specific integration requires otherwise — and that is disclosed in our integration documentation.

• Environment separation: development, staging and production environments are logically isolated. Customer data does not live in non-production environments.
• Network controls: production services sit behind firewalls and private networking where appropriate. Public endpoints are limited to authenticated API and application traffic.
• Backups: encrypted backups are taken on a regular schedule and stored in the same UK jurisdiction as primary data.
• Availability target: enterprise tiers include a 99.9% uptime SLA. We design for redundancy at the application and database layer.

3 · Encryption

3.1 In transit

All traffic between your browser, our API and integrated third-party services uses TLS 1.2 or higher. We do not serve the application over unencrypted HTTP in production.

3.2 At rest

Customer data stored in Mortartec databases and object storage is encrypted at rest using industry-standard AES-256 (or equivalent provider-managed encryption). Encryption keys are managed through our cloud provider's key management service and are not shared with customers or third parties except as required for lawful disclosure.

3.3 Secrets & credentials

API keys, integration tokens and internal service credentials are stored in a dedicated secrets manager — not in source code or configuration files committed to version control.

4 · Access controls

Access to Mortartec — both for your team and for our staff — follows least-privilege principles.

• Role-based access (RBAC): brokerages configure which users can view, edit or submit cases. Permissions can be scoped by role (e.g. adviser, admin, compliance reviewer).
• Authentication: user accounts are protected by password policy requirements. Multi-factor authentication (MFA) is supported and recommended for all users with access to live case data.
• Session management: inactive sessions time out. You can sign out of all active sessions from account settings.
• Internal access: Mortartec employees only access production customer data when necessary for support or engineering — and only with appropriate authorisation and logging.

5 · Monitoring, testing & resilience

We maintain continuous monitoring of production systems for availability, error rates and anomalous access patterns. Security-relevant events — failed login bursts, permission changes, API errors on integration endpoints — are logged and reviewed.

• Vulnerability management: dependencies and infrastructure are patched on a regular cadence. Critical security patches are prioritised.
• Application security: code changes go through review before deployment. We use automated scanning for common vulnerability classes where practical.
• Logging: platform actions on cases (who changed what, when) are recorded for audit purposes — see our Compliance page for how this supports FCA record-keeping.

6 · Third-party integrations

Mortartec connects to official data partners — including TransUnion for credit data and Twenty7Tec for live lender criteria — via authenticated API connections. We do not scrape lender websites or store broker portal credentials in plain text.

Each integration is scoped to the minimum data required for the function (sourcing, affordability, compliance checks). API traffic to partners is encrypted in transit. Where partners impose their own security and audit requirements, we comply with those as a condition of the commercial relationship.

A list of sub-processors and data recipients is available on request for enterprise customers conducting vendor due diligence.

7 · Incident response

If we become aware of a security incident that affects customer data, we will investigate promptly, contain the issue and notify affected customers without undue delay where required by law or contract.

Our incident process includes: identification and triage, containment, forensic review, remediation, and post-incident review to prevent recurrence. Where a personal data breach occurs, we will assess notification obligations under UK GDPR and inform the ICO where required.

To report a suspected vulnerability or security concern, email security@mortartec.co.uk. Please include enough detail for us to reproduce the issue. We aim to acknowledge reports within two business days.

8 · Your responsibilities

Security is shared. Even with strong platform controls, brokerages must protect their own accounts and devices:

• Use strong, unique passwords and enable MFA where available.
• Limit Mortartec access to staff who need it; remove accounts when people leave the firm.
• Do not share login credentials or leave sessions open on shared machines.
• Report suspicious activity to us immediately at security@mortartec.co.uk.

This page is reviewed periodically and was last updated May 2026. Material changes will be posted here.