One Constellation
Security

ISO 27001 at One Constellation: What Our Certification Covers

When you onboard a customer through One Constellation, you hand us passport scans, biometric captures, beneficial ownership structures, sanctions match dispositions and — in some workflows — the contents of a suspicious transaction report before it reaches a financial intelligence unit. This is what our ISO/IEC 27001 certification says about how that data is governed, what the certificate's scope does and does not reach, and how to use it properly in your own third-party risk file.

Published: July 2026 Category: Security Read time: ~12 minutes
Quick Answer
One Constellation holds ISO/IEC 27001 certification and a SOC 2 Type II attestation. ISO 27001 certifies our information security management system — the governance, risk assessment, control selection and audit cycle that surrounds the platform — rather than any individual product feature. Our certificate is issued by [[CONFIRM: certification body]], accredited by [[CONFIRM: accreditation body]], under certificate number [[CONFIRM: number]], against the 2022 edition of the standard. The scope reads: [[CONFIRM: verbatim scope statement from the certificate]]. For your own third-party risk obligations — MAS Guidelines on Outsourcing and the Technology Risk Management Guidelines, FCA SYSC 8, or DORA in the EU — our certificate is evidence you can cite in your file, but it does not discharge your obligation to assess us yourself. This article explains what it covers, what it deliberately does not, and what to ask us for.

Most vendor security pages stop at the logo. That is not useful to a compliance officer who has to defend a supplier decision to a supervisor, so this one goes further: which classes of data the platform actually concentrates, how the 2022 Annex A control themes map onto them, where ISO 27001 ends and SOC 2 Type II begins, and the specific artefacts we will hand you during due diligence.

If you want the general explainer of how ISO 27001 works as a standard — clauses, Annex A structure, the audit cycle, what a scope statement means — the sections below cover the parts that bear on this platform. Where a claim concerns our certificate specifically rather than the standard generally, it is stated as such.

Why a Compliance Platform Is a Concentrated Risk

Information security risk is a function of what you hold. A project management tool holds task lists. A KYC and AML platform holds a different order of material, and the risk assessment underneath our ISMS has to start from that inventory rather than from a generic SaaS template.

Across the modules our customers deploy, the platform processes:

  • Government identity documents. Passport, national ID and driving licence images, machine-readable zone data, and NFC chip reads where the document supports it — captured through KYC verification and biometric verification workflows.
  • Biometric material. Face images, liveness capture sequences and derived match templates. Biometric data attracts elevated obligations under the GDPR as a special category, and under Singapore's PDPA as sensitive personal data.
  • Beneficial ownership graphs. Layered corporate structures unwrapped through UBO discovery across 190+ jurisdictions, including the registry evidence supporting each ownership link.
  • Screening outcomes and dispositions. PEP, sanctions and adverse media match records, the analyst's decision on each, and the reasoning recorded against it. This is not merely personal data — it is a record of which individuals a regulated firm has assessed as elevated risk.
  • Behavioural and transaction data. Expected activity profiles, alert history and disposition trails from transaction monitoring.
  • Pre-submission regulatory filings. SAR and STR content drafted in the platform before it is filed through goAML, STRO, FinCEN or AUSTRAC via SAR / STR reporting.
The risk that is specific to this category
The last item is the one that changes the calculus. A breach of ordinary customer data is a privacy and fraud event. A breach of suspicious activity report content is a tipping-off exposure — it can prejudice an active investigation and, in several jurisdictions, create criminal liability for the reporting institution. That single data class justifies control decisions across the ISMS that a general-purpose SaaS provider would not need to make, and it is why segregation, access control and logging around the reporting module are treated differently from the rest of the platform.

Scope Is the Certificate

An ISO 27001 certificate is bounded by a scope statement naming the activities, systems and locations the management system covers. Everything the certificate asserts is true only inside that boundary. This is the single most commonly misread element of the standard, and it is where a careful reviewer should start.

The failure mode is well known in vendor due diligence: a supplier certifies corporate IT at head office, displays the certificate mark on the website, and the production platform holding customer data sits entirely outside the certified boundary. Nothing about that is fraudulent — the certificate is genuine — but it evidences almost nothing about the service being purchased.

Our scope statement reads: [[CONFIRM: paste the verbatim scope statement from the face of the certificate]].

Read it against the modules you are deploying. If a service you intend to consume is not within that boundary, ask us — either the scope covers it and the wording should be clearer, or it does not and you should know that before you sign. We would rather have that conversation during procurement than during your next supervisory inspection.

Verify us the way you would verify anyone
Our certificate names the certification body and its accreditation body, and it can be checked on the issuing body's public register rather than taken from a PDF we sent you. Unaccredited certification exists, is legal, and is close to worthless for assurance purposes — so the accreditation mark matters more than the certificate itself. Apply that test to us. A vendor that objects to independent verification is telling you something.

How the 2022 Annex A Themes Map to This Platform

The 2022 edition of the standard restructured Annex A into 93 controls across four themes, consolidated from 114 controls across 14 domains in the 2013 edition. Controls are not a checklist to be adopted wholesale — an organisation selects them against its own risk assessment and records the inclusions and exclusions in a Statement of Applicability, which is itself mandatory.

What follows is how the four themes bear on a platform holding the data classes above.

Organizational — 37 controls

The heaviest theme, and for us the most consequential. It covers supplier and cloud service relationships, threat intelligence, incident management and information classification. For a platform operating across 15+ jurisdictions the material questions are subprocessor governance, data residency commitments per customer, and the boundary between One Constellation and the wider group following the KFin Technologies relationship. If you have data residency requirements under MAS, DORA or a national data protection regime, this theme is where the answers live — ask for the subprocessor list and the residency position for your deployment.

People — 8 controls

The smallest theme and the one most often underestimated. Support engineers who can see a customer's identity documents in the course of resolving a ticket represent a real risk surface. The relevant controls concern pre-employment screening for staff with production access, contractual confidentiality terms, security awareness training, and a disciplinary process that is documented rather than notional. Ask what production access support staff hold, whether it is time-bounded and approved, and whether it is logged.

Physical — 14 controls

Perimeters, entry controls, equipment siting and secure disposal. For a cloud-delivered platform much of this theme is inherited from data centre providers and evidenced through their own certifications, with our own corporate premises in Singapore covered directly. The question worth asking is which physical controls are inherited and which are ours — the Statement of Applicability should make that division explicit rather than leaving it implied.

Technological — 34 controls

Access control, cryptography, secure development, logging and monitoring, plus several of the controls introduced in 2022 — data masking, data leakage prevention, configuration management, web filtering and secure coding. For this platform the ones that matter most to a reviewer are encryption of identity document images at rest and in transit, how biometric templates are stored relative to the source images, segregation between customer tenants, and the integrity of audit trails. Every alert disposition, rule change and screening decision needs to be attributable and tamper-evident, because that trail is what your supervisor will eventually examine.

Read the exclusions, not the inclusions
A Statement of Applicability listing 93 applicable controls tells you almost nothing — it is the excluded controls, and the justification recorded against each, that carry the information. Where a control has been excluded, the reasoning should identify a risk that genuinely does not apply rather than a control that was inconvenient. Ask us for the exclusions relevant to the modules you are deploying. A summary scoped to your services is a fair middle ground if the full document is commercially sensitive.

Why We Hold Both ISO 27001 and SOC 2 Type II

The two are not substitutes and they answer different questions. We maintain both because our customer base spans both conventions — European and Asia-Pacific institutions generally ask for ISO 27001, North American institutions generally ask for SOC 2.

  • ISO/IEC 27001 is a certification against an international standard, issued by an accredited certification body. It confirms that a management system exists, functions, and has been independently audited. It produces a public certificate and a scope statement — and it will never show you a control that failed.
  • SOC 2 Type II is an attestation report produced by a licensed CPA firm against the AICPA Trust Services Criteria. It tests whether specific controls operated effectively across a defined period, and it reports exceptions where they occurred. It is issued under NDA rather than published. Our report covers [[CONFIRM: report period]] and was issued by [[CONFIRM: CPA firm]].

The practical guidance for your file: the ISO certificate tells you the governance system is real and where its boundary sits; the SOC 2 report tells you what a third party tested and what they found. If you can obtain both — and from us you can — read the SOC 2 report for the exceptions and read the ISO certificate for the scope.

Neither is a privacy certification. ISO 27001 is an information security standard; it does not evidence lawful processing under the GDPR or PDPA. ISO/IEC 27701 extends the framework into privacy information management, and that is a separate question you should ask separately.

Using Our Certificate in Your Regulatory File

For most of our customers ISO 27001 is not itself a regulatory requirement. It appears as evidence inside a third-party risk obligation that is mandatory — and the obligation sits with you, not with us.

The MAS Technology Risk Management Guidelines and Guidelines on Outsourcing expect a Singapore-regulated institution to assess and monitor the security posture of service providers handling its data. The FCA's outsourcing and operational resilience expectations do the same in the United Kingdom, and DORA sets out explicit ICT third-party risk management requirements for EU financial entities. Each asks the regulated firm to demonstrate that its providers were assessed properly.

Five steps that make our certificate genuinely useful in that file:

1

Record the certificate and its scope, not just the fact of it

Your outsourcing register should carry the certificate number, the certification body, the accreditation body, the issue and expiry dates and the verbatim scope statement. "Vendor is ISO 27001 certified" is not a due diligence record.

2

Map the scope to the services you actually consume

Note which modules you have deployed and confirm each falls inside the certified boundary. Where it does not, record what compensating assurance you obtained instead.

3

Obtain the exclusions relevant to your workflows

Request the Statement of Applicability exclusions that bear on your services, and record your assessment of whether the justification is reasonable for your risk appetite.

4

Set your own review cadence and trigger events

The certificate runs on a three-year cycle with surveillance audits in years one and two. Diarise the surveillance dates and treat a material change in our subprocessors, residency position or scope as a trigger for re-review rather than waiting for the cycle.

5

Keep the risk assessment yours

Our certification is an input to your assessment. It is not the assessment. A supervisor reviewing your file wants to see that you read the scope, understood the exclusions, asked about the gaps and formed your own view — not that you filed our PDF.

What certification does not claim
Certification does not assert that we have never had a security incident, and it would be dishonest to imply otherwise. What it asserts is that there is a defined process for identifying risk, detecting and containing incidents, reporting them, and improving afterwards — and that an accredited auditor has tested that process rather than taking our word for it. Any vendor presenting ISO 27001 as a guarantee against breach has misunderstood their own certificate.

What We Provide During Due Diligence

Rather than making you extract these one at a time, the following are available to prospective and existing customers on request through your account contact:

  • The ISO/IEC 27001 certificate, including scope statement, certification body, accreditation mark and validity dates.
  • Statement of Applicability exclusions relevant to the modules in your deployment, with the recorded justification for each.
  • The SOC 2 Type II report, under NDA, including any exceptions identified during the review period.
  • Subprocessor list and data residency position for your specific deployment and jurisdictions.
  • Incident notification terms — notification thresholds, timelines and escalation contacts, as they will appear in your contract.
  • Completed security questionnaires in the common industry formats, plus a mapping to your own template where you use one.
  • Penetration test summary — [[CONFIRM: what is shareable, at what level of detail, and under what conditions]].

If your assessment needs something not on this list, ask. The purpose of certification is to make this conversation shorter and more evidenced, not to end it.

For the wider regulatory picture across the jurisdictions we operate in, see our regulations hub, and for how the platform handles the underlying compliance workflows, the compliance portal overview.

Compliance Infrastructure You Can Put in Front of an Auditor

KYC, KYB, AML screening and transaction monitoring built for firms that have to evidence every decision — with the security governance documentation to support your third-party risk file.

← FinCEN CTA & BOI Reporting All Articles
Scroll to Top