Security

Our approach

Terrafa is a young company, and we would rather describe our security position accurately than dress it up. What follows is what we do, what we are committed to, and where we have not got to yet.

Three principles shape the rest of this page:

• Take the least we need. A read-first connection to the systems you already run, scoped to the data the platform actually reasons over. We do not ask for write access we do not need, and we do not copy what we do not use.
• Assume the record will be examined. The platform is built on an append-only record so that any value can be replayed to its sources. The same instinct applies to our own systems: access to production is logged, and the log is not editable by the person who generated it.
• Say when we are not sure. The platform refuses a decision its inputs cannot support. We apply the same standard here — where an assurance is a plan rather than a fact, this page says so.

Data ownership

Your data is yours, completely. It is never shared, pooled or sold. We do not use one customer's operational data to improve the picture we give another, and we do not train models on your data for anyone's benefit but yours unless you ask us to in writing.

What remains ours is the platform itself and what it learns about running operations in general — the methods, not your numbers.

At the end of a contract, we return or delete your data on the terms agreed with you, and confirm the deletion in writing.

Where your data lives

Terrafa runs on Amazon Web Services, in the eu-north-1 region in Stockholm, Sweden. That is inside the European Economic Area, and it is where your data sits unless a different region is agreed with you in writing before anything moves.

Infrastructure is defined as code and applied through version control. The running configuration matches a definition that has been reviewed and committed, rather than an accumulation of manual changes made under pressure and remembered by one person. An environment can be rebuilt from that definition.

Production is separated from development, and production data is never copied into a development environment.

Encryption

• In transit. Everything is served over HTTPS. Plain HTTP requests are redirected, and the minimum accepted protocol version is TLS 1.2.
• At rest. Stored data is encrypted with AES-256, applied by default across the AWS storage services we use.
• Credentials. Terrafa never stores or has sight of a user's password — authentication is handled by Amazon Cognito, described in the next section. Application secrets are kept out of source control.

Access control

Authentication is handled by Amazon Cognito, AWS's managed identity service. That is a deliberate choice rather than a convenient one: identity is the part of a system where a home-grown implementation is most likely to be quietly wrong for years, and using Cognito puts AWS's own engineering, patching and threat monitoring behind the front door.

• Terrafa never stores, transmits or has sight of your password. Cognito holds credentials, enforces password policy, and issues short-lived tokens.
• Multi-factor authentication and account-takeover protection are available through Cognito and configured per deployment.
• Access to production infrastructure is granted to named individuals on the principle of least privilege, for a defined role, never to a shared account.
• Terrafa staff do not access customer data as a matter of routine. Where support requires it, access is authorised and scoped to the problem in hand.
• Within the platform, customer administrators control their own users, roles and permissions.

Read-first connection

Connectors to historian, laboratory, terminal management, trading and risk, and file-based systems are read-first and non-invasive by design. The default posture is a read-only credential against the system of record.

Those systems stay the systems of record for their functions. Continuum does not replace them and does not need to write to them to do its job. Where a customer chooses to enable a write-back — pushing a reconciled value into a downstream system — that is explicit, scoped, agreed in the deployment, and can be turned off.

Connections are declarative and reviewable: you can see what is being read, from where, and how often.

Auditability

The platform is built on an append-only record. The state of an operation at any moment is a replay of its history, which means records are added rather than overwritten and a value can always be traced to the readings, assumptions and approvals behind it.

That design has a security consequence worth stating: tampering with a historical value is not a matter of editing a row. An audit becomes a lookup rather than an investigation, and the same property that satisfies a commercial auditor also makes unauthorised change detectable.

Secure development

• All code lives in version control. Nothing reaches production that has not been committed and merged.
• Every change is peer-reviewed before it is deployed.
• Infrastructure changes take the same path as application changes — defined as code, reviewed, and applied from the reviewed definition.
• Developers work against test data. Production data is not used for development.
• Secrets are kept out of source control.

Automated dependency scanning, secret scanning in the build pipeline and independent penetration testing are planned rather than running. They are listed in section 14, because a control that is on a roadmap belongs on the roadmap and not in this list.

Logging and monitoring

Authentication events are recorded by Amazon Cognito, and administrative actions against our AWS account are recorded by AWS. Those records are retained and cannot be edited by the accounts that generate them.

Customer-facing audit records within the platform are available to customer administrators, so you can see what happened in your own environment without asking us.

Centralised alerting on unusual access patterns is part of the work described in section 14, not something we claim today.

Resilience and continuity

Infrastructure is defined as code, so an environment is rebuilt from its definition rather than reconstructed from memory. That is the primary recovery mechanism, and it is exercised every time the definition is applied rather than kept in a folder against the day it is needed.

Data is backed up monthly, and backups are encrypted. Stated plainly, that sets a recovery point objective of up to one month — and we would rather you read that here than discover it in an incident.

Two things make that less severe than it sounds. Continuum is read-first: the systems it connects to remain the systems of record, so a substantial part of the picture is rebuilt by reconnecting to them rather than restored from our backup. And the append-only design means recovery is a replay of history, not a reconstruction of state.

If your deployment needs a tighter recovery point than monthly, say so early. It is a supported conversation and it is written into the service terms, but it changes the shape of the deployment, so it is better raised before design than after.

People

• Everyone at Terrafa is bound by written confidentiality obligations that survive the end of their engagement.
• Right-to-work verification is completed before someone starts.
• Access to production systems and to customer data is removed when someone leaves.

We are a small team, and access is correspondingly narrow. The list of people who can reach production is short enough to hold in your head, which is its own control — and one we intend to replace with a formal access review before it stops being true.

Suppliers and sub-processors

We keep the supply chain deliberately short, and it is short enough to name.

Amazon Web Services is our only sub-processor with access to customer operational data. It provides our hosting, storage, content delivery and authentication, under the AWS Data Processing Addendum.

The other tools we use — email, collaboration, accounting — hold business contact details rather than customer operational data, and are engaged under written terms. We do not operate a customer relationship management system, so your contact details are not sitting in one.

Customers are told about changes to the sub-processor list on the terms set out in their agreement with us. A current list is available on request.

Incident response

We maintain a documented process for identifying, containing, investigating and resolving security incidents, with named responsibilities and defined escalation.

If an incident affects your data, we will tell you without undue delay, with what we know, what we are doing, and what we recommend you do — and we will follow it with a written account of the cause and the corrective action once the investigation is complete.

Where a personal data breach is likely to result in a risk to people's rights and freedoms, we report it to the Information Commissioner's Office within 72 hours of becoming aware of it, as described in our Privacy Policy. Where we act as processor for a customer, we notify the customer so that they can meet their own obligation as controller.

Assurance and certification

Terrafa does not currently hold ISO/IEC 27001 certification or a SOC 2 report. We would rather say that here than have you discover it in a questionnaire.

Our controls are built along the lines those frameworks describe, and formal certification is on the roadmap as the company scales. In the meantime we will complete your security questionnaire, walk your technical team through the architecture, and agree specific security commitments in the contract.

The following are planned rather than in place, and are listed here so that nothing above has to overstate itself:

• Independent penetration testing of the platform.
• Automated dependency and secret scanning in the build pipeline.
• Centralised security alerting on unusual access patterns.
• A formal periodic access review.
• ISO/IEC 27001 certification or an equivalent independent assurance report.

We will update this page as each one lands. The version and date at the top tell you when it last changed.

This website specifically

The page you are reading is a static site, and its security position is simple enough to state completely:

• It is served only over HTTPS. Plain HTTP requests are redirected, and the minimum accepted protocol version is TLS 1.2.
• Origin storage is private. Public access is blocked at the bucket, and the content delivery network reads it through an origin access control — a direct request to the storage bucket returns 403.
• Standard security response headers are applied to every response.
• There are no logins and no databases behind this site. It carries one form, the Continuum sign-up page, which posts the name, email address and organisation you type to our sign-up service over HTTPS. Nothing else on the site collects anything from you.
• It sets no cookies, runs no analytics and embeds no third-party trackers. The one external request it makes is for typefaces, as described in our Privacy Policy.

Access to preview versions of this site is by link rather than by password. Anyone holding the link can open the page, so please treat a preview link as shareable-by-anyone-who-has-it and pass it on accordingly.

Reporting a vulnerability

If you believe you have found a security vulnerability in this website or in the Continuum platform, please tell us at info@terrafa.uk. Include enough detail to reproduce it, and give us a reasonable opportunity to fix it before disclosing it publicly.

We will acknowledge your report, keep you informed of progress, and credit you if you would like us to. We will not pursue legal action against anyone who reports a genuine issue in good faith, who stays within the scope of testing their own access allows, and who does not access, modify or exfiltrate other people's data in the course of finding it.

Please do not run automated scanning, load testing or denial-of-service testing against our systems without written agreement first.

Contact us

For security questions, questionnaires, or to request our current sub-processor list: