Security Statement

This Security Statement describes the technical and organisational measures that Blackwellen Limited (company number 16482166, registered office 61 Bridge Street, Kington, Herefordshire, HR5 3DJ, United Kingdom) (Blackwellen, we, us) uses to protect Propvora (the Service) and the data held in it.

This statement is provided for information. It describes our practices at the effective date shown above, which will change over time as the Service and the threats it faces evolve. It is not a contractual warranty. Our binding security commitments for personal data that we process on a customer's behalf are set out in our Data Processing Agreement (the DPA), and our overall contractual commitments are in our Terms of Service. If this statement and either of those documents are inconsistent, those documents prevail.

We have deliberately written this statement conservatively. Where a control depends on one of our infrastructure providers, we say so. Where we have not yet implemented something, or have not had it independently verified, we do not claim it.

In this statement, Customer means the business or individual that holds a Propvora subscription; Workspace means a Customer's account area in the Service, including any portals connected to it; Customer Data means data uploaded to or created in a Workspace; and Personnel means our employees, directors and contractors.

Security in a cloud service is a shared responsibility. Some controls are ours, some belong to our infrastructure providers, and some can only be exercised by the Customer.

2.1 What we are responsible for

• designing, building and operating the Service securely, including the application code, database access rules and Workspace isolation;
• choosing, configuring and overseeing our infrastructure providers and subprocessors;
• protecting the credentials, keys and secrets that the Service uses;
• controlling and monitoring access by our Personnel; and
• detecting, investigating and responding to security incidents affecting the Service.

2.2 What our infrastructure providers are responsible for

Our providers are responsible for the physical security of data centres, the underlying hardware, network and virtualisation layers, and the platform services they run for us, as described in their own security documentation.

2.3 What the Customer is responsible for

• deciding who is invited to the Workspace and to each portal, assigning appropriate roles, and removing access promptly when people leave or no longer need it;
• making sure users choose strong, unique passwords, keep them confidential and turn on multi-factor authentication where it is offered;
• securing the devices, browsers, email accounts and networks they use to access the Service;
• deciding what data to put into the Service, keeping it accurate, and having a lawful basis to process it;
• configuring sharing links, portal access, integrations and automations appropriately; and
• telling us promptly about any suspected unauthorised access to their account or Workspace.

Many security incidents in software-as-a-service products start with a compromised user account, not with the platform itself. The steps in section 2.3 are therefore among the most effective protections available.

The Service runs on established cloud providers rather than on servers we own. At the date of this statement, our core infrastructure providers are:

• Supabase, for the primary database (PostgreSQL), authentication and file storage;
• Vercel, for application hosting and edge delivery;
• Cloudflare, for R2 object storage and for DNS, content delivery and web application firewall services;
• Stripe, for payment processing, including Stripe Connect for partner payouts. Card details are entered on Stripe-hosted or Stripe-provided payment forms and are not stored by us;
• Resend, for transactional email; and
• Sentry, for error monitoring.

Our AI features use OpenAI, Microsoft Azure OpenAI Service and NVIDIA, as described in our AI Disclaimer and AI Use Policy. We also use MapTiler for maps and geocoding.

Our default is to host product data in the United Kingdom or the European Economic Area where our providers make that available. Some providers process certain data in other countries, including the United States. The region used by each provider, and the transfer safeguard that applies where data leaves the UK, are listed on our subprocessors page.

We select providers that publish information about their own security programmes, and many of them hold independent certifications or attestation reports for their services. Those certifications belong to the providers and relate to their services; they are not certifications of Blackwellen or of the Service as a whole (see section 15 (Assurance and certifications)).

4.1 In transit

Connections between your browser or device and the Service are encrypted using TLS 1.2 or higher. We do not serve the application over unencrypted HTTP; requests made over HTTP are redirected to HTTPS. Connections between the Service and our infrastructure providers, including the database, storage and email services, are also encrypted in transit using TLS.

4.2 At rest

Customer Data stored in our database and file storage is encrypted at rest using AES-256, using encryption provided and managed by our infrastructure providers. Backups maintained by our providers are encrypted at rest in the same way.

4.3 Passwords and secrets

User passwords are never stored in plain text. They are handled by our authentication provider and stored only as salted, one-way cryptographic hashes. API keys, service credentials and other secrets used by the Service are held in our hosting providers' secret management facilities, are not committed to source code, and are not exposed to users' browsers. Privileged database credentials are used only by server-side code.

4.4 Files and downloads

Documents you upload to a Workspace, such as certificates, tenancy agreements and onboarding documents, are held in private storage protected by access rules, and access is checked against the requesting user's permissions before a file is made available. Some media is public by design because you choose to publish it, for example images in a supplier's public profile or gallery, so don't upload anything to a public-facing feature that you wouldn't want anyone to see. Where the Service lets you create share links for portals or documents, anyone who has the link may be able to access what it points to until it expires or is revoked, so share links should be treated as confidential.

The Service is multi-tenant: many Customers' Workspaces are held in the same database. Keeping each Workspace's data separate is one of our most important controls.

We isolate Workspaces using database row-level security (RLS) in PostgreSQL. Records that belong to a Workspace carry that Workspace's identifier, and RLS policies enforced by the database itself check that the signed-in user is an active member of that Workspace, with an appropriate role, before a row can be read or changed. Because these checks are enforced in the database, they apply even if an error in application code requests the wrong data.

Portal users (for example tenants, landlords, owners, applicants, guarantors, contractors and leaseholders) are given access only to the specific records shared with them through the relevant portal, not to the Workspace as a whole. Supplier workspaces and customer homes are separate Workspaces with their own isolation.

In addition to RLS, the application checks permissions on the server before carrying out sensitive actions, and server-side functions that need elevated database access are limited in number, reviewed with particular care, and not callable directly from the browser.

Platform administrators can access cross-Workspace information only through a separate administration area, subject to the controls described in section 7 (Access control and least privilege).

Users can sign in to the Service with an email address and password, or with Google sign-in. Where you use Google sign-in, Google authenticates you and we do not receive your Google password.

• Passwords: passwords are verified by our authentication provider, and the Service sets minimum password requirements. Users should choose a long, unique password, ideally generated by a password manager.
• Multi-factor authentication (MFA): MFA using a time-based one-time password from an authenticator app is required for all Blackwellen platform administrators. For Customers and their team members, MFA is strongly encouraged; where it is offered in your account settings you should turn it on, and where it is not yet offered for your account type we recommend using Google sign-in with 2-Step Verification enabled on your Google account.
• Sessions: sessions are managed by our authentication provider using signed tokens that expire and are refreshed. Signing out ends the session on that device. If you think someone else has access to your account, change your password and contact us.
• Account recovery: password resets are sent to the registered email address and use single-use, time-limited links.
• Abuse protection: we rely on our authentication provider's rate limits and on Cloudflare's network protections to reduce the risk of brute-force and credential-stuffing attacks.

We will never ask you for your password by email, phone or chat. Messages claiming to be from Propvora that ask for your password or an authentication code should be treated as phishing and reported to us.

7.1 Customer access

Within a Workspace, access is controlled by roles. Workspace owners decide who is invited and what role they have. Roles limit which modules, records and actions each person can use. We recommend giving each person the least access they need, reviewing members regularly, and removing leavers promptly.

7.2 Blackwellen access

Our Personnel do not routinely access Customer Data. Access is limited to people who need it to provide, support, secure or maintain the Service, and only to the extent necessary. Typical reasons include investigating a support request you have raised, diagnosing a fault, responding to a security incident, or meeting a legal obligation.

• Access to production systems and provider consoles is restricted to named individuals and protected by MFA.
• Platform administration functions are separated from the customer-facing application and protected by additional checks, including mandatory MFA.
• Privileged actions in the administration area are recorded in an audit log.
• Access rights are reviewed periodically and removed promptly when no longer needed.
• Shared accounts are avoided; where a provider requires a shared credential, it is held in a password manager with restricted access.

We keep logs to help us operate the Service, detect misuse and investigate incidents. These include:

• application and server logs from our hosting provider;
• authentication events from our authentication provider, such as sign-ins and password resets;
• error reports captured by Sentry, which we configure to limit the personal data included where we reasonably can;
• firewall and traffic data from Cloudflare; and
• audit records of significant actions in the Service, such as changes to Workspace membership and roles, other sensitive changes, and actions taken by platform administrators. The audit log is designed to be append-only, so that entries cannot be edited after they are written.

Some audit information is visible to Workspace owners in the Service. Logs are retained only for as long as reasonably needed for security, troubleshooting and legal purposes, and are subject to access controls. Our handling of log data that contains personal data is described in our Privacy Notice.

We monitor errors and unusual activity, and we use alerts from our providers to help us identify incidents. We do not operate a staffed 24-hour security operations centre.

Our database is backed up using the backup capabilities of our database provider, and files are stored on provider infrastructure designed for durability. Backups are encrypted at rest and protected by the same access controls as production data.

The frequency of backups, how long they are kept and the point to which data can be restored depend on the capabilities and plan of the relevant provider, and may change. We do not currently publish a guaranteed recovery point objective or recovery time objective, and nothing in this statement is an uptime or availability commitment. Any service commitments are those set out in our Terms of Service.

Because the Service runs on major cloud platforms, it benefits from their resilience features. However, a serious outage at a provider could make the Service, or parts of it, unavailable until the provider recovers. We keep the source code of the Service under version control, separate from production, so that it can be redeployed.

Backups are a safeguard against disaster, not a substitute for your own records. Customers should export and keep copies of documents and records they are legally required to retain, such as gas safety records, tenancy agreements and financial records, using the export features in the Service.

We aim to build security into the Service from the start rather than adding it later. Our development practices include:

• writing the Service in a type-checked language and using established frameworks that provide protections against common web vulnerabilities, such as cross-site scripting;
• validating input on the server, using parameterised database queries, and enforcing authorisation on the server rather than relying on the user interface;
• relying on our framework's built-in protections against cross-site request forgery for state-changing actions, and checking the origin of sensitive requests;
• progressively strengthening browser security headers;
• keeping secrets out of source code and out of browser-delivered code;
• reviewing changes before they are released, with extra care for changes to authentication, database access rules, payments and file handling;
• testing changes in non-production environments before release, and using seeded or synthetic data in those environments rather than copies of Customer Data; and
• tracking third-party software dependencies and updating them when security fixes are released.

Where we use AI coding tools in development, their output is reviewed by a person before release in the same way as any other change.

We monitor security advisories for the frameworks, libraries and services the Service depends on, and we check our dependencies for known vulnerabilities when updating them. We assess each issue by severity and exploitability in the context of the Service, and prioritise fixes accordingly, with critical issues treated as urgent.

We do not currently commission regular independent penetration tests, and we do not claim to have done so. As the Service grows we intend to introduce independent testing, and we will update this statement when we do.

Reports from security researchers are welcome and are handled under section 16 (Responsible disclosure).

We maintain an incident response process for identifying, containing, investigating and recovering from security incidents. When we become aware of a suspected incident, we:

1. assess the report and, where it is credible, take steps to contain it, such as revoking credentials, blocking traffic or disabling an affected feature;
2. investigate what happened, what data and which Workspaces are affected, and the likely consequences;
3. remediate the cause and restore normal service;
4. notify those who need to know, as described below; and
5. record the incident, its effects and the remedial action taken, and review what we can learn from it.

Where we act as processor: if a personal data breach affects Customer Data that we process on a Customer's behalf, we will notify the affected Customer without undue delay after becoming aware of it, and provide the information and assistance set out in the Data Processing Agreement, so that the Customer, as controller, can meet its own obligations to notify the Information Commissioner's Office and affected individuals.

Where we act as controller: if a personal data breach affects data for which Blackwellen is controller, such as account, billing or website data, we will notify the Information Commissioner's Office within 72 hours of becoming aware of it where the law requires, and will tell affected individuals without undue delay where the breach is likely to result in a high risk to their rights and freedoms.

We may also tell Customers about significant incidents that do not involve personal data but affect the security or availability of the Service. Customers should report suspected incidents affecting their account to info@blackwellen.com.

Blackwellen is a small company. Everyone who has access to production systems or Customer Data is bound by confidentiality obligations in their employment or engagement terms, is made aware of their security and data protection responsibilities, and is given only the access they need.

Personnel must use MFA on business accounts, keep devices used for work updated and protected by a screen lock and disk encryption, and report suspected incidents immediately. When someone leaves or changes role, their access is removed or adjusted promptly.

Before we use a provider that will process personal data, we consider its security practices, its data protection terms and where it will process data. We put in place written terms with each provider that will process Customer Data on our behalf that meet the requirements of UK data protection law, and we flow down obligations consistent with our Data Processing Agreement.

Our current subprocessors are listed on our subprocessors page, with their purpose and processing location. Customers can object to a new subprocessor as described in the DPA.

Blackwellen does not currently hold ISO 27001 or SOC 2 certification, and the Service has not been independently certified against any security standard. We do not currently provide a third-party audit report for the Service.

Blackwellen is registered with the Information Commissioner's Office (registration number ZB905402).

Customers who need more information for their own due diligence, for example to complete a supplier security questionnaire, can contact us at info@blackwellen.com. We will answer reasonable questions where we can do so without compromising the security of the Service or other Customers, and may ask you to agree confidentiality terms before sharing sensitive detail.

If you believe you have found a security vulnerability in the Service, please tell us at info@blackwellen.com with the subject line "Security report". Please include a description of the issue, the steps needed to reproduce it, the affected URL or feature, and its potential impact. Screenshots or a short proof of concept are helpful.

16.1 What we ask of you

• Report the issue to us promptly and give us a reasonable period to fix it before you disclose it to anyone else.
• Only test against accounts and Workspaces that you own or have explicit permission to test.
• Do not access, change, copy or delete data belonging to anyone else. If you accidentally access such data, stop, do not keep it, and tell us.
• Do not degrade the Service for others. Do not carry out denial-of-service testing, high-volume automated scanning, spam or social engineering of our Personnel, Customers or providers, and do not attempt physical access.
• Do not test our providers' infrastructure directly; report issues in their services to them under their own programmes.
• Do not demand payment as a condition of sharing details of a vulnerability.

16.2 What we will do

• acknowledge your report within a reasonable time and keep you informed of progress;
• investigate and, where we confirm an issue, work to fix it in a timeframe that reflects its severity;
• let you know when the issue is resolved; and
• with your permission, credit you for the discovery.

16.3 Safe harbour

If you make a good-faith effort to comply with this section, we will consider your research to be authorised, we will not pursue or support civil or criminal action against you in relation to it, and, if a third party brings action against you in connection with research that complied with this section, we will make it known that your activities were conducted with our authorisation. This does not authorise research that goes beyond what is described here, and we cannot authorise testing on behalf of third parties.

We do not currently operate a paid bug bounty programme.

We review this statement when our security practices or providers change materially, and at least once a year. The effective date at the top of the page shows when it was last updated.

Security questions and reports: info@blackwellen.com. Postal address: Blackwellen Limited, 61 Bridge Street, Kington, Herefordshire, HR5 3DJ, United Kingdom. For how we handle personal data, see our Privacy Notice.