An organization can implement strong technical safeguards and still fail to meet ISO 27001 compliance requirements. Certification concerns a working information security management system, not a collection of security tools. For a materials R&D team, that distinction becomes clear when an auditor asks not whether formulation files are encrypted, but who approved access, how the decision addressed a documented risk, and what happened when a collaborator left.
Table of Contents
- Follow a formulation through the control themes
- Connect safeguards rather than counting them
- Evaluate suppliers against the service you use
What ISO 27001 Compliance Really Requires
ISO 27001 certifies a working management system, not a completed controls checklist. Compliance means establishing, implementing, maintaining and continually improving an information security management system, or ISMS, suited to the organization's activities and risks.
The ISO standard listing identifies ISO/IEC 27001:2022, published in October 2022, as the edition replacing the 2013 edition, with requirements centered on operating and improving an ISMS. It's globally applicable, rather than a rulebook for a particular industry or technology.
Say a laboratory protects proprietary formulations, experimental datasets and electron microscope images. Its researchers use laboratory instruments, cloud repositories and external testing suppliers. Buying encryption software addresses only part of that environment. The organization also needs to decide which activities fall within its ISMS, who owns the risks and how security decisions are checked.
The management cycle connects those decisions to daily work.
Three outputs make the system tangible:
- A defined scope identifies the activities, information and dependencies being managed.
- A Statement of Applicability records risk-based control decisions and their justification.
- Operating evidence demonstrates that people follow the processes and address failures.
For a complementary framework overview, DevArmor's guide to ISO 27001 provides useful context alongside a clause-by-clause assessment.
The practical distinction is simple: a policy describes intended behavior. An auditor also needs records showing what happened to the laboratory's data, accounts, suppliers and systems.
Clauses 4 to 10 at a Glance
| Clause | Requirement area | What auditors check first |
|---|---|---|
| Clause 4 | Context of the organization and ISMS scope | Documented scope, interested parties and interfaces |
| Clause 5 | Leadership | Approved information security policy, assigned roles and authorities |
| Clause 6 | Planning | Risk assessment and treatment results, objectives and Statement of Applicability |
| Clause 7 | Support | Resources, competence records, awareness and documented information |
| Clause 8 | Operation | Risk treatment carried out, change control and supplier control |
| Clause 9 | Performance evaluation | Monitoring records, internal audit reports and management review minutes |
| Clause 10 | Improvement | Nonconformity log, root cause analysis and corrective action effectiveness |
The mandatory clauses describe how the organization manages information security. Annex A provides a reference set for determining safeguards. Don't confuse permission to justify a control exclusion with permission to omit a management-system requirement.
For an R&D director, the table is also an interview map. An auditor might begin with the scope statement, ask who owns formulation-security risks, then follow a selected risk through its treatment decision and implementation records. Different employees should describe compatible responsibilities, even when they use different terminology.
Read in the order decisions are made
Start with context and leadership. A risk assessment won't be meaningful if the team hasn't agreed whether contract laboratories, instrument workstations or research cloud environments fall within the boundary.
Next, examine planning. The risk register should explain which events could compromise research information and why the chosen treatments are appropriate. The Statement of Applicability translates those decisions into a controlled record of applicable safeguards.
Then examine support and operation. A laboratory manager might know that a procedure exists but lack training, time or authority to execute it. Auditors distinguish a documented responsibility from a responsibility someone can carry out.
Finally, examine evaluation and improvement. Management needs a way to learn whether the processes work and to correct weaknesses without waiting for an external audit.
Practical rule: Follow a research asset through the clauses. If you can't connect its owner, risk, treatment, operating record and review outcome, investigate the missing connection.
The table's evidence column is a starting point, not a universal audit script. An auditor can request related records, interview process owners and sample different systems to determine whether the ISMS operates coherently.
Defining the ISMS Scope and Leadership Duties
A scope statement should let someone unfamiliar with your organization distinguish the managed environment from its surroundings. A statement such as “all research information” is too vague if nobody can explain whether it includes instrument computers, archived images or a partner laboratory's transfers.
The ISO overview of ISO/IEC 27001 explains the management-system requirements, including organizational context, leadership and risk management; conformity cannot exclude requirements in Clauses 4 through 10.
Build a boundary someone else can understand
Identify internal and external issues. Record the circumstances that affect information security, such as customer confidentiality commitments, applicable obligations and dependence on specialist equipment. For formulation research, distinguish unpublished composition data from information already approved for publication.
Identify interested parties and requirements. Consider customers, funders, employees, regulators and partner laboratories. Translate relevant expectations into specific obligations, such as restricting access to a customer-sponsored project or retaining approved experimental records.
Set the organizational and technical boundary. Name the sites, business units, laboratories, cloud tenants and datasets included. Explain exclusions, but don't use them to ignore dependencies that affect in-scope information.
Document interfaces and dependencies. Trace a result from an analytical instrument into an electronic lab notebook and onward to a model service. Identify where information crosses organizational boundaries and who controls each connection.
The scope doesn't need every implementation detail. Supporting inventories and data-flow diagrams can hold those details, provided they agree with the scope and remain accessible.
Make leadership duties observable
Top management must approve the information security policy, assign responsibilities and authorities, provide resources and establish measurable objectives. Delegating operational work to IT doesn't remove leadership's responsibility for the ISMS.
Useful objectives address an actual research workflow. Management could track access-revocation time after a chemist leaves, training completion among staff handling confidential formulations, or overdue corrective actions affecting instrument data.
For each objective, record the owner, measurement method, review interval and intended result. Keep evidence of resource decisions too, such as approval for backup testing or staff time for supplier assessments.
Test the scope before approving it: give it to someone outside the project and ask them to identify the boundary, important interfaces and accountable leaders. Ambiguous answers indicate drafting work, not an auditor's lack of familiarity.
How to Run Risk Assessment and Write the Statement of Applicability
A useful risk register describes events and consequences, not just assets. “Formulation database” is an asset; “a former collaborator retains access to unpublished formulation data” is a risk scenario that someone can assess and treat.
The process below separates the decisions so their evidence remains traceable.
Record the decision before selecting the safeguard
Define risk criteria and a repeatable methodology. Establish how assessors judge likelihood, impact and acceptability. Use descriptions that distinguish disclosure of a published technical sheet from disclosure of a commercially sensitive formulation.
Identify confidentiality, integrity and availability risks. Consider unauthorized access to formulations, corrupted instrument exports and loss of access to a cloud repository. Describe the affected workflow and consequence, not merely a possible technical failure.
Evaluate likelihood and impact. Record the reasoning behind the assessment and account for safeguards already operating. A score without an explanation won't help a future reviewer understand why the team prioritized the risk.
Choose a treatment. Reduce the risk through safeguards, avoid the activity, share or transfer an aspect of the exposure, or accept it under your criteria. A supplier contract doesn't automatically eliminate your organization's remaining responsibilities.
Determine necessary controls and compare them with Annex A. Check that the reference set doesn't reveal an overlooked safeguard, and document defensible exclusions. The ISO/IEC 27001 reference overview describes this risk-based comparison and the requirement to record applicability decisions rather than implement every reference control identically.
Obtain accountable approval. Name treatment owners, record approval of the treatment plan and obtain risk-owner acceptance of residual risk. Distinguish the person implementing a control from the person authorized to accept the remaining exposure.
Write the Statement of Applicability. Record inclusion or exclusion, justification and implementation status. Add owners, linked risks and evidence locations so reviewers can follow the decision into practice.
For a supplementary explanation of the assessment workflow, the following video can support team discussion.
Make the linkage visible
An SoA that marks everything implemented without supporting records isn't a useful account of operating controls. Neither is a risk register whose treatments have no identifiable implementation.
The following is an illustrative row, not a prescribed template or review frequency.
| SoA field | Example entry |
|---|---|
| Control | A.5.15, access control |
| Applicability | Included |
| Linked risk | Unauthorized access to unpublished formulation data |
| Justification | Restrict research information to authorized project participants |
| Status | Implemented |
| Owner | IT security lead |
| Evidence | Quarterly project-access review, reviewer sign-off and completed removal tickets |
Documentation, Change Control and Operating Evidence
A controlled document explains the process. An operating record shows that someone performed it. An access policy and a signed access review have different purposes, and an auditor may need both.
Maintain the ISMS scope, approved information security policy, risk assessment and treatment results, Statement of Applicability, security objectives and records needed to demonstrate process execution. Apply version control, approval, access restrictions and retention arrangements appropriate to each record.
Record competence, not just attendance
Under the support requirements, determine the competence needed for security-relevant work. A chemist exporting confidential results, a laboratory manager approving access and a cloud administrator configuring storage have different responsibilities.
A practical competence record contains:
- Role and responsibility: Which security-relevant task the person performs.
- Training or experience: What supports their ability to perform it.
- Completion evidence: The training date or other attributable record.
- Effectiveness assessment: A practical check, assessment result or supervisor evaluation.
Attendance alone may not establish that someone can correctly share a restricted dataset. A short exercise using a representative project folder can reveal misunderstandings before they affect real information.
Follow an electronic lab notebook change
Say the laboratory introduces a new electronic lab notebook. The change owner records its purpose, affected datasets, integrations and intended access model, then arranges a risk reassessment and supplier review before deployment.
Keep the approval, migration checks, training records and validation results together. If the new service changes a control's implementation, revise the relevant SoA entry and supporting procedure rather than leaving the old description in place.
Bright Defense's discussion of ISO 27001 changes identifies Clause 6.3 as requiring planned ISMS changes and A.5.23 as addressing security across cloud-service acquisition, use, management and termination. That means cloud governance belongs in the change workflow, not only in initial procurement.
| Change trigger | Evidence to generate or reassess |
|---|---|
| Move experimental data to a different cloud region | Approved change, data-flow update, risk reassessment and responsibility allocation |
| Add an AI model service | Supplier review, permitted-data decision, retention assessment and access approval |
| Onboard a contract laboratory | Information-sharing requirements, supplier assessment and authorized transfer method |
| Replace the identity provider | Role mapping, migration tests, privileged-access checks and access recertification |
| End a supplier relationship | Access removal, data return or deletion evidence and documented offboarding |
Not every change needs every document rewritten. The change owner should identify affected risks, controls, obligations and evidence, then record why other areas remain unchanged.
For an AI service, for example, determine whether unpublished formulations leave the approved environment and what the supplier may retain or reuse. For an instrument integration, verify whether service accounts can alter raw results or only retrieve approved exports.
Generate evidence when the architecture changes. Reconstructing approvals before an audit can't establish that the right decision happened before deployment.
Keep change tickets linked to assessments and implementation checks. That gives an auditor a sequence they can inspect rather than a folder of disconnected documents.
Annex A Controls Mapped to a Materials R&D Lab
| Theme | Controls | Example controls | Materials R&D example |
|---|---|---|---|
| Organizational | 37 | Supplier relationships, information classification, cloud services security | Classifying formulation IP and governing contract laboratories |
| People | 8 | Screening, security awareness, remote working, responsibilities after termination | Onboarding and offboarding of contract chemists |
| Physical | 14 | Physical security perimeters, equipment siting, secure disposal | Lab access control and secure disposal of storage drives |
| Technological | 34 | Access rights, cryptography, secure development, logging, backup, vulnerability management | Role-based access and encryption for experimental datasets |
| Total | 93 | Reference set only; selection is risk-based | Each selected control needs an SoA row and evidence |
The IBM ISO 27001 compliance overview describes the 93 reference controls across 37 organizational, 8 people, 14 physical and 34 technological controls, with selection based on risk. The totals organize the reference set; they aren't implementation targets or a maturity score.
Follow a formulation through the control themes
Organizational controls establish how the company handles information and external relationships. A research leader classifies unpublished formulation files, identifies their owner and defines conditions for sharing them with a contract laboratory.
The evidence might include classification rules, project-sharing approvals and supplier requirements. Labeling a file confidential is only useful if employees know what that classification changes about storage, access and disclosure.
People controls address responsibilities across the employment or engagement lifecycle. A contract chemist needs instructions appropriate to the project, an authorized account and a clear route for reporting suspected information loss.
Offboarding should account for more than the main user account. Review project invitations, remote-access permissions, shared credentials and continuing confidentiality responsibilities where applicable.
Physical controls protect facilities, equipment and storage media. A workstation connected to an analytical instrument may contain locally stored results even if the approved research repository is cloud-based.
Evidence can include laboratory entry authorization, visitor records and disposal records for drives. Equipment removal should trigger a check for stored research information, not merely an update to the asset inventory.
Technological controls implement protections such as access restrictions, cryptography, logging, backups and vulnerability management. A formulation project might use restricted roles, isolated data environments and encryption, with activity records supporting investigation.
Don't stop at configuration screenshots. Test whether a user outside the project can access the files, whether restored data is usable and whether administrators investigate relevant alerts.
Connect safeguards rather than counting them
A single research workflow crosses these themes. Classification establishes sensitivity; project roles restrict access; laboratory controls protect the instrument workstation; offboarding removes a departing chemist's permissions.
For practical handling measures to consider alongside that workflow, data protection guidance from Verbex provides a complementary operational reference. Select measures because they address your information flows, not because another organization uses them.
A certificate also needs context. An external laboratory's certified office process may not cover its testing facility, and a cloud provider's certificate doesn't establish that your own tenant configuration is appropriate.
Evaluate suppliers against the service you use
Keep supplier evidence tied to the actual engagement. Useful assessment questions include:
- Certificate scope: Does it cover the legal entity, location and service handling the research data?
- Data location: Where will information be stored and processed, including subcontracted services?
- Audit currency: How current is the available assurance evidence, and what relevant limitations or findings remain?
At Polymerize, we hold ISO 27001, ISO 27017, ISO 27018 and SOC 2 certifications. We follow industry security standards, regularly conduct security audits and application testing, and provide the reports to customers.
Those credentials support supplier assessment, but customers still need to evaluate their intended workflow, permissions and information-sharing decisions. Start with the risk register, then give each selected control an accountable owner and evidence that reflects its actual operation.
Internal Audit, Management Review and Audit Evidence
| Evidence | What the auditor checks | Typical source |
|---|---|---|
| Internal audit reports | Audit programme covers all ISMS processes and auditors are independent | Audit schedule and findings log |
| Management review minutes | Top management reviews performance, risks and objectives and records actions | Signed meeting minutes and action list |
| Access review records | Privileged and standard access recertified on schedule | Identity platform exports and sign-off |
| Backup restore tests | Restores are tested, not only assumed | Restore test logs with dates and results |
| Nonconformity log | Root cause identified and corrective action verified as effective | Corrective action register |
| Supplier assessments | Suppliers reviewed against risk and certificate scope confirmed | Assessment files and current certificates |
Performance evaluation requires decisions about what to measure, how to measure it and when to evaluate the results. For an R&D environment, useful measures could include overdue project-access reviews, failed restore tests and unresolved supplier-assessment actions.
Choose measures that help an accountable manager make a decision. A large count of completed training sessions says little if the employees handling confidential exports still misunderstand sharing restrictions.
Separate checking from doing
Plan internal audits around the ISMS processes, relevant risks and previous findings. Define the scope and criteria, select auditors who can evaluate the work objectively, and avoid having someone audit their own implementation.
An internal audit should test execution, not merely confirm that documents exist. For example, sample a completed laboratory project and compare the closure procedure with access removals, archived records and supplier offboarding.
Management review has a different purpose. Top management considers performance, audit outcomes, changes affecting the ISMS, risks, objectives and opportunities for improvement. Record decisions with named owners and follow-up actions, rather than retaining only a presentation deck.
Correct the cause and verify the result
Say an internal audit finds that a scheduled access review omitted a formulation project. The immediate correction is to review that project's access and remove inappropriate permissions.
The corrective-action record should go further. If the cause was that nobody assigned an owner when the project began, update the project-creation workflow to require ownership and include the project in the review schedule.
At the next review, check whether the project was included and whether newly created projects also have owners. That is an effectiveness check, rather than a statement that the action was completed.
Evidence test: Another reviewer should be able to identify who performed the activity, when it happened, what they checked and how exceptions were resolved.
Auditors sample rather than inspect every transaction. Dated, attributable records across different teams and systems make it possible to distinguish a repeatable process from an isolated demonstration.
Certification Audit Stages and Surveillance
| Stage | What the auditor does | What the organization provides | Timing |
|---|---|---|---|
| Stage 1 | Documentation and readiness review of scope, policy, risk assessment, SoA and internal audit records | Controlled document set and management review minutes | Before Stage 2 |
| Stage 2 | Operational audit sampling selected controls and interviewing process owners | Access reviews, restore tests, change records and supplier files | Main certification assessment |
| Surveillance | Samples continued ISMS operation within the certified scope | Current evidence and corrective-action register | According to the certification body's surveillance programme |
| Recertification | Reviews continued conformity and effectiveness across the certification cycle | Evidence history, reviews and improvement records | Before the applicable certification cycle expires |
Compliance and certification aren't interchangeable. An organization can operate its ISMS against the standard before an external certification body assesses it. Certification adds independent assessment within a stated scope; it doesn't certify every activity the organization performs.
Show readiness before demonstrating operation
During Stage 1, the auditor examines whether the ISMS is sufficiently defined and developed for the operational assessment. A polished policy won't resolve missing scope boundaries, an unfinished risk assessment or absent internal evaluation.
During Stage 2, expect the auditor to follow actual transactions. A request to share formulation data might lead to the project authorization, user permissions, supplier agreement and activity record.
Prepare process owners to explain their own work accurately. They don't need memorized clauses, but they should know their responsibilities, where records are stored and how they handle exceptions.
Resolve findings according to their significance
If the auditor identifies nonconformities, respond with corrections, cause analysis and corrective actions appropriate to the finding. The certification body determines the evidence and verification needed for its certification decision; don't assume all findings require identical handling.
After certification, maintain the evidence as operations change. Surveillance and recertification assess continued conformity, so an unchanged audit folder isn't sufficient when the laboratory has introduced new model services or external testing partners.
Before the readiness assessment, confirm that you have:
- Internal evaluation: Completed audit work and management review records with decisions.
- Operational history: Access reviews, restore tests and implemented change records.
- Supplier coverage: Assessment files for relevant in-scope relationships.
- Finding follow-up: Owners, actions and verification evidence for identified weaknesses.
Agree the audit programme and timing with the certification body. Don't treat an assumed timetable as a requirement established by your own ISMS documents.
Start With a Scope Statement and Gap Assessment
Start by describing the environment you need to manage, not by purchasing a compliance-document bundle. For a materials organization, the highest-value starting point is usually the relationship between research information, the people using it and the systems carrying it.
The investment can be worthwhile without being effortless. In the 2024 Austrian status report published by CIS Certification, 93% of surveyed ISO 27001-certified organizations said the standard's benefits outweighed its costs and effort.
Turn the boundary into a remediation plan
Use this sequence as a practical starting plan, not a promised certification timetable:
Draft the scope. Identify included activities, sites, datasets and interfaces. Record justified exclusions and the dependencies that still need management.
Map existing evidence to requirements. Compare policies, procedures and records with the clause table. Separate missing documentation from processes that exist on paper but haven't operated.
Assess priority research risks. Begin with formulation IP, instrument data and critical research repositories. Assign owners who can make treatment decisions.
Draft the SoA and assign gaps. Record applicability, implementation status, ownership and evidence locations. Give missing safeguards a responsible person and a remediation deadline.
Test the system internally. Audit the defined scope, record findings and verify corrective actions before relying on an external assessment to discover basic weaknesses.
The checklist below provides a compact way to organize that initial work.
Keep the gap assessment honest. “Evidence unavailable” and “control not implemented” require different actions, even when both prevent you from demonstrating readiness.
Write the scope statement this week. Then ask a colleague outside the implementation team whether they can identify the boundary, relevant interfaces and exclusions without additional explanation.
Polymerize helps materials R&D teams bring fragmented experimental information into a secure foundation for AI-guided research. Visit Polymerize to discuss your research-data workflow, or use our contact form to request a security whitepaper or security audit reports for your supplier assessment.
Put your R&D data to work
See how materials teams use Polymerize to plan fewer experiments and reach target properties faster.
