ISO 27001 for Research Data Security

ISO/IEC 27001 shows up constantly in funder security questionnaires, cloud-repository vendor
assessments, and industry-sponsored clinical trial contracts, but it is not a research-data
standard at all — it is a general-purpose information security management system (ISMS)
standard that happens to be the certification a research institution’s IT security office, a
cloud data repository, or a contract research organization is most likely to already hold or be
asked to hold. This guide explains what ISO/IEC 27001:2022 actually certifies, why research
institutions and their vendors increasingly need it (or an equivalent), how it relates to —
and differs from — research-data-specific trust frameworks like CoreTrustSeal, which
Annex A control areas matter most for research data specifically, and what the certification
process actually involves.

What ISO/IEC 27001 is (and isn’t)

ISO/IEC 27001:2022 — formally “Information security, cybersecurity and privacy
protection — Information security management systems — Requirements” — is published
jointly by the International Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC). It is the third edition, replacing the 2013 version, and it
specifies the requirements for establishing, implementing, maintaining, and continually
improving an information security management system (ISMS): the governance
structure — policies, risk assessments, roles, controls, internal audits, management review
— an organization uses to manage information security risk on an ongoing basis, not a
one-time technical checklist.

Two things this standard is not, which matters directly for a research-administration
audience:

It is not research-specific. ISO 27001 was written for any organization,
in any sector, of any size. It says nothing about data management plans, research data
lifecycles, dataset citation, or scholarly reuse. A university, a hospital, a bank, and a
software vendor can all pursue the identical certification for the identical reasons.
Certification applies to a defined scope, not automatically to everything an
organization does. An institution or vendor is certified against a specific, documented
ISMS scope — a particular data center, a particular cloud product, a particular business
unit. “Digital Science is ISO 27001 certified” does not by itself tell you whether the specific
research-data repository product you’re evaluating sits inside that certified scope; the
certificate’s scope statement is the thing to actually check, not the vendor’s marketing page.
CASRAI’s guide to figshare as a data repository
covers a concrete example of this exact distinction — ISO 27001 certification of the parent
organization’s information security practices, held alongside (not instead of) a separate
question of repository-level trustworthiness certification.

Why research institutions pursue ISO 27001 certification or alignment

ISO 27001 wasn’t written with research data in mind, but demand for it inside the research
sector has grown for reasons specific to how research is now funded, sponsored, and
outsourced:

Funder and sponsor security questionnaires increasingly reference it directly.
Research institutions handling sensitive or human-subjects data, and their subcontracted cloud
vendors, are asked with growing frequency to attest to a named information-security framework
rather than a general statement of “we take security seriously.” ISO 27001 is one of the small
number of internationally recognized answers to that question — alongside SOC 2 and, in the
United States federal context, NIST SP 800-171.
NIH explicitly accepts it as an alternative to a U.S.-specific framework.
NIH’s Security Best Practices for Controlled-Access Data Repositories and the
companion best practices for users of controlled-access data require institutions to attest
alignment with NIST SP 800-171 (protecting Controlled Unclassified Information in nonfederal
systems) — but explicitly permit non-U.S. institutions unable to attest to NIST SP 800-171 to
instead align with ISO/IEC 27001/27002. For a research institution or cloud repository outside
the United States handling NIH controlled-access genomic or clinical data, ISO 27001 is
frequently the practical, internationally recognizable route to satisfying that requirement,
rather than an optional extra.
EU-funded research increasingly treats it as a due-diligence signal. Horizon
Europe guidance on selecting digital tools and cloud services for funded projects points
investigators toward providers that hold recognized security certifications — ISO 27001 named
specifically — as part of assessing whether a tool or cloud provider meets the data-security
expectations attached to a grant agreement, alongside GDPR compliance. See CASRAI’s guide to
GDPR and data protection compliance in research
for how the two intersect: ISO 27001 addresses the security-controls side of GDPR Article 32
(“appropriate technical and organisational measures”), while GDPR itself is a legal obligation
ISO 27001 doesn’t independently satisfy.
Industry-sponsored clinical trials expect it from technology vendors as standard
due diligence. Sponsors and contract research organizations (CROs) evaluating EDC
(electronic data capture), CTMS (clinical trial management system), IWRS/IRT (randomization and
supply), and ePRO vendors commonly treat ISO 27001 — often alongside SOC 2 Type II — as a
baseline vendor-assurance expectation before a system touches trial data, particularly where
the trial involves personal health information subject to contractual confidentiality and data
security clauses in the clinical trial agreement. Which certification a given sponsor actually
requires varies by trial location, data type, and sponsor policy — there is no single global
mandate — but the underlying due-diligence pattern (ask the vendor for a current certificate
and scope statement, not a marketing claim) is consistent across sponsors.
Cloud repository and CRIS vendor selection. When an institution is choosing
a cloud-hosted repository, a research information system (CRIS), or any third-party platform
that will store sensitive research data, ISO 27001 certification of the vendor is one of the
concrete, checkable facts — alongside the vendor’s own subprocessor list and data-residency
commitments — that a security review can actually verify, rather than relying on the vendor’s
self-description.

ISO 27001 vs. research-data-specific trust frameworks: related, not interchangeable

A common point of confusion — understandable, since both get described loosely as
“trustworthy repository” credentials — is treating ISO 27001 as equivalent to, or a
substitute for, certifications built specifically around research data stewardship. They test
different things:

ISO/IEC 27001 certifies an organization’s information security management
system: how it identifies and treats security risk, who can access what, how incidents are
handled, how suppliers are vetted. It says nothing about metadata quality, persistent
identifiers, long-term preservation planning, or a designated community’s ability to
understand and reuse a dataset.
CoreTrustSeal certifies a
repository’s trustworthiness as a place to deposit and preserve research data specifically —
assessed against 16 requirements covering organizational infrastructure, digital object
management, and technical infrastructure (see CASRAI’s CoreTrustSeal certification guide for
the full requirement list and process). Security is one dimension among many it examines, not
the whole assessment.
ISO 16363 (audit and certification of trustworthy digital repositories) is
the “formal” tier of the same trust-framework family CoreTrustSeal anchors at the “core” tier
— a full external audit rather than a peer-reviewed self-assessment. It is a completely
separate ISO standard from ISO 27001, despite both carrying the ISO name; don’t conflate an
“ISO-certified repository” claim without checking which ISO standard is actually meant.
FAIR (Findable, Accessible, Interoperable, Reusable) is a set of guiding
principles for dataset stewardship, not a certification at all — see CASRAI’s FAIR data checklist. A
dataset can be fully FAIR-compliant and sit in an ISO 27001-certified environment, or either
one independently of the other; the two are complementary, not overlapping.

In practice, the strongest data-security posture for a research data repository combines
more than one of these: ISO 27001 (or an equivalent like SOC 2 or NIST SP 800-171 alignment)
covering the organization’s information security management, and a research-data-specific
credential like CoreTrustSeal covering the repository’s stewardship practices specifically. A
funder or journal mandate that says “deposit in a trustworthy repository” is very likely asking
about the second category, not the first — check which one is actually being requested
before assuming ISO 27001 alone satisfies it.

Annex A control areas most relevant to research data

ISO/IEC 27001:2022’s Annex A lists 93 controls organized into four themes: organizational
(37 controls), people (8 controls), physical (14 controls), and technological (34 controls) —
a restructuring from the prior 2013 edition’s 114 controls across 14 domains. The detailed
implementation guidance for each control lives in the companion standard, ISO/IEC
27002 (not itself certifiable — it’s a code of practice, not a management-system
standard). An organization doesn’t have to implement every control; Annex A functions as a
reference checklist against which the organization documents, in its Statement of
Applicability, which controls apply to its specific risk assessment and why, including
formal justification for excluding any that don’t.

For a research institution or repository specifically, three control areas do most of the
practical work in protecting research data:

Access control (concentrated in the organizational and technological
themes, e.g. identity management, access rights, privileged access, and authentication).
This is what actually operationalizes tiered access to sensitive or controlled-access research
datasets — the same principle behind a data-use agreement’s access restrictions, but
enforced technically rather than just contractually. For a repository handling human-subjects
or otherwise sensitive data, auditors will expect to see documented access-provisioning and
de-provisioning processes, not just a stated policy.
Cryptography (a technological-theme control area covering encryption
policy and key management). Directly relevant to data at rest in a repository and data in
transit during deposit, download, or transfer between collaborating institutions —
particularly load-bearing for controlled-access genomic, clinical, or otherwise
re-identifiable datasets where encryption is often an explicit condition of a data access
agreement, not just good practice.
Supplier and third-party relationships (an organizational-theme control
area covering information security in supplier agreements, monitoring supplier performance,
and managing changes to supplier services). This is the control area that governs cloud
repository and CRIS vendor risk specifically — how an institution’s own ISMS extends
coverage to a third-party platform it depends on but doesn’t operate directly. It’s also the
mechanism by which a cloud vendor’s own ISO 27001 certification becomes relevant evidence
within the institution’s supplier-risk assessment, rather than a self-contained fact evaluated
in isolation.

Other Annex A areas — incident management, business continuity, and information security
in project management — are also directly applicable to a research computing environment,
but the three above are the ones most specifically tied to research-data-security decisions a
research administrator or data steward is actually asked to make (which repository to use,
what encryption to require, how to structure access).

The certification process, at a high level

ISO 27001 certification is issued by an accredited, independent certification body (not by
ISO itself, which only publishes the standard) after an external audit. The process has
several distinct stages:

Build the ISMS. The organization defines the ISMS scope, conducts a formal
risk assessment, selects and implements applicable Annex A controls, documents its Statement
of Applicability, and runs the management processes the standard requires — internal audits,
management review, a documented improvement process — typically for some period before
seeking certification, so there’s a real operating history to audit against.
Stage 1 audit (readiness review). The certification body reviews ISMS
documentation — scope statement, risk assessment methodology, Statement of Applicability,
evidence of internal audit and management review — and determines whether the organization
is ready to proceed to a full audit.
Stage 2 audit (certification audit). The certification body verifies the
ISMS is actually implemented and operating as documented — on-site or remote evidence review,
staff interviews, and sampling of specific Annex A controls in practice, not just on paper.
Certificate issuance. A certificate is valid for three years from issue,
provided ongoing audits continue to pass.
Surveillance audits. Shorter, narrower-scope audits typically conducted
annually (roughly at the end of year 1 and year 2 of the three-year cycle), sampling a subset
of controls rather than re-auditing the whole ISMS.
Recertification audit. A more comprehensive audit in year three, similar in
scope to the original Stage 2 audit, required to maintain continuous certification into the
next three-year cycle.

For a research institution evaluating a vendor’s claim, the practically useful documents are
the current certificate (which names the accredited certification body, the
certificate number, and the validity dates) and the scope statement (which
states exactly what part of the organization and which services the certification actually
covers) — both of which a legitimate ISO 27001-certified organization should be able to
provide on request, along with confirmation that the certification body itself is accredited by
a recognized national accreditation body.

Frequently asked questions

Is ISO 27001 required for NIH grants?

Not as a blanket requirement across all NIH funding. It becomes directly relevant for
controlled-access data governed by NIH’s Genomic Data Sharing Policy and related
controlled-access frameworks, where NIH’s security best-practices documents allow non-U.S.
institutions unable to attest to NIST SP 800-171 to instead align with ISO/IEC 27001/27002.
U.S. institutions are generally expected to attest to NIST SP 800-171 directly. Check the
specific data-access agreement or repository’s requirements rather than assuming either
standard applies by default.

Does ISO 27001 certification satisfy a “deposit in a trustworthy repository” funder
mandate?

Usually not by itself. A funder or journal requiring deposit in a “trustworthy” or
“certified” repository is typically asking about a research-data-specific credential like
CoreTrustSeal or ISO 16363, which assess
repository-level stewardship practices, not an organization’s general information security
management. Confirm which specific credential the mandate names before assuming ISO 27001
alone is sufficient.

What’s the difference between ISO 27001 and SOC 2 for a research data vendor?

Both are widely used vendor-assurance credentials, but they differ structurally: ISO 27001
is a certifiable management-system standard with a fixed, published Annex A control set,
audited by an accredited certification body against that fixed standard. SOC 2 is an
attestation report (not a certification) produced by a licensed CPA firm against the AICPA’s
Trust Services Criteria, and its scope and the specific controls tested can vary more between
vendors. Many cloud vendors serving research institutions carry both; which one a specific
funder, sponsor, or institutional security review actually requires depends on that
organization’s own policy.

Does ISO 27001 cover GDPR compliance?

Partially. ISO 27001’s Annex A controls map well onto the “appropriate technical and
organisational measures” GDPR Article 32 requires for protecting personal data, and many
organizations use ISO 27001 as evidence supporting a GDPR compliance program. But ISO 27001
alone does not make an organization GDPR-compliant — GDPR imposes legal obligations (lawful
basis, data subject rights, breach notification timelines, international transfer mechanisms)
that sit outside ISO 27001’s scope. A dedicated privacy extension, ISO/IEC 27701, exists
specifically to extend an ISMS to cover privacy information management more directly. See
CASRAI’s guide to GDPR and data protection compliance in research
for the legal-compliance side.

How long does ISO 27001 certification typically take?

Industry sources commonly cite a range of roughly three to six months from a genuinely
audit-ready ISMS to certificate issuance, on top of however long it takes the organization to
build the ISMS itself beforehand (which varies widely depending on existing security maturity).
Treat any specific timeline a vendor quotes as vendor-specific, not a fixed rule the standard
itself sets.