Implementing a Dual ISO 9001 / ISO 27001 Management System

Why integrate at all

The case for an integrated management system (IMS) is almost embarrassingly obvious once you've mapped both standards side by side. ISO 9001 and ISO 27001 are both structured around the Plan-Do-Check-Act cycle. They share substantial clause-level overlap: both require management review (clause 9.3 in both), internal audit (9.2), nonconformity management and corrective action (10.1/10.2), risk assessment (6.1), and continual improvement (10). Running these as separate systems means separate document sets, separate audit calendars, separate review meetings, separate corrective action registers, and separate training programs — for processes that are, at their core, addressing the same management infrastructure questions.

The overlap in our case was significant enough that running parallel systems would have meant approximately 60% duplicated effort. That's not a small inefficiency. In a 35-person engineering organization where process overhead competes directly with delivery capacity, 60% duplication in compliance activities is a real cost.

Our consulting partner's initial concern — expressed with the carefully modulated alarm of someone who has seen integration projects go badly — was scope creep. An IMS that tries to serve too many masters ends up serving none of them well, and we would have to be deliberate about where the boundaries were. That concern turned out to be correct and worth heeding.

The unified document structure

The architecture we settled on has three layers. At the top, a single Integrated Management System Manual — about twelve pages — that describes the organization's context, the scope of both certifications, and the high-level policy commitments. This document satisfies the "documented information" requirements in both standards without being the policy itself.

Beneath the manual, a shared policy framework with policies organized by domain rather than by standard. An Information Security Policy satisfies ISO 27001 clause 5.2; a Quality Policy satisfies ISO 9001 clause 5.2; a Risk Management Policy covers the risk assessment requirements of both. Where a policy speaks to one standard more than the other, it's tagged accordingly in the document header. Auditors can navigate the structure because the tagging is consistent.

The third layer is the unified risk register. This was the piece that took the most thought. ISO 27001's risk register is information-asset-focused: you identify assets, identify threats to confidentiality/integrity/availability, assess likelihood and impact, select controls from Annex A. ISO 9001's risk assessment is process-focused: you identify processes, identify what could prevent them from achieving intended outputs, decide what to do about it. These are structurally different enough that forcing them into a single register row format produced a document that was useful to neither standard.

The solution was a two-tab register. One tab for information security risks (ISO 27001 format), one tab for quality/process risks (ISO 9001 format), with a shared severity scale so that risk prioritization was comparable across both. The management review meeting could then look at both in sequence without switching tools. This felt like a compromise, and it was, but it was a workable compromise — which is most of what integrated management systems are.

Where the standards diverge

The integration story has two places where it becomes genuinely complicated, and being clear-eyed about them early saves time later.

The first is ISO 27001's Annex A control set. Annex A contains 93 controls across four themes (organizational, people, physical, technological) in the 2022 revision. These controls have no equivalent in ISO 9001. The Statement of Applicability (SoA) — the document that declares which Annex A controls apply, which are excluded, and why — is a pure ISO 27001 artifact. It lives alongside the IMS but is not integrated with the quality system because there's nothing to integrate it with. This is fine. Not everything needs to be integrated; the integration is only valuable where there's genuine process overlap.

The second divergence is ISO 9001's customer satisfaction and product realization requirements. Clause 8 of ISO 9001 (Operation) covers planning and control of operational processes, design and development, control of externally provided processes, and customer satisfaction measurement. ISO 27001 has some of this — supplier relationships appear in Annex A control 5.19 through 5.22 — but the customer satisfaction measurement requirement in ISO 9001 clause 9.1.2 is broader and more operationally focused than anything in 27001. We maintained separate customer satisfaction measurement processes that were clearly tagged as ISO 9001 obligations and not part of the security management system.

The rule of thumb that emerged: integrate where the process is the same activity viewed through a different lens (risk assessment, audit, review, corrective action). Maintain separate tracks where the standard requires something with no equivalent in the other.

The combined internal audit program

Running a single internal audit program for both standards was one of the clearest wins of the integration. The alternative — two separate audit calendars, two separate auditor pools, two separate report formats — would have consumed roughly twice the calendar time and produced documents that were harder to act on because they lived in separate systems.

The key requirement was auditor competence. Both ISO 9001 and ISO 27001 require that internal auditors be competent to audit the standard in question (clause 9.2 in both). We ran a combined internal auditor training — two days covering both standards, with emphasis on the Annex A controls that are 27001-specific — and certified six engineers as internal auditors against both standards. This pool then rotated through audit assignments on a schedule that ensured each part of the IMS was audited at least once per certification cycle.

The audit report format was unified: findings are tagged by standard (9001, 27001, or both), but the finding structure — observation, evidence, applicable clause, recommended action — is identical regardless of which standard generated it. This matters for the corrective action process; if a finding's format varies by standard, the corrective action workflow has to handle that variation downstream.

The management review meeting

Both standards require a management review at planned intervals. Both specify what the review must cover. The lists overlap substantially — audit results, nonconformity status, objectives performance, resource adequacy — with ISO 27001 adding security incident trends and ISO 9001 adding customer satisfaction data and product conformity.

We run one annual management review meeting that covers both. The agenda runs roughly as follows:

1. Previous review action item status (shared)
2. Internal audit results — quality findings (ISO 9001)
3. Internal audit results — security findings (ISO 27001)
4. Customer satisfaction data and external feedback (ISO 9001)
5. Security incident trend summary (ISO 27001)
6. Quality objectives performance vs. targets (ISO 9001)
7. Security objectives performance vs. targets (ISO 27001)
8. Risk register review — quality risks (ISO 9001)
9. Risk register review — information security risks (ISO 27001)
10. Resource review and continual improvement opportunities (shared)
11. Decisions and action items (shared)

The meeting runs three to four hours with the full leadership team. The minutes serve as the management review record for both certifications. Auditors from both bodies have reviewed this structure and found it satisfactory, which is the only validation that matters in practice.

Corrective action management

A unified nonconformity register is one of the more concrete payoffs of integration. We use a single tool (in practice, a structured table in our internal wiki with defined columns and a review workflow) where every nonconformity — whether sourced from an internal audit, a customer complaint, a security incident, or a surveillance audit finding — enters the same process.

Each record has a standard field that takes values of ISO9001, ISO27001, or BOTH. The corrective action workflow — root cause analysis, action defined, action implemented, effectiveness check, record closed — is identical regardless of the standard field. The only difference is that ISO 27001 nonconformities may trigger a review of the relevant Annex A controls, which is an additional step in the workflow for that standard tag.

This structure means a single person can manage the corrective action backlog without needing to context-switch between two different systems. It also means the management review meeting sees a single list of open nonconformities rather than two separate lists that might be inconsistently prioritized.

The scope problem

The most important practical warning about IMS implementation is scope creep, and it deserves explicit treatment rather than a footnote.

Both standards require that you define a scope for the certification. The ISO 27001 scope is your ISMS scope — the information assets and processes covered by the security management system. The ISO 9001 scope is the products and services the QMS covers. These scopes can legitimately differ, and in many organizations they should.

The failure mode is allowing the ISMS scope to expand to cover every business process because "everything processes information." This is technically true and practically disastrous. An ISMS that covers the entire organization is an ISMS that nobody can actually maintain. The scope should be the minimum set of processes and assets that covers your material information security risks and satisfies your customers' compliance requirements. Everything else is outside scope, and that's fine.

Similarly, the QMS scope should describe what you're certifying — for a software consultancy, this might be "delivery of custom software development services" — not every internal process. Internal IT, HR, finance: these may support the QMS processes, but they don't need to be inside the QMS scope to satisfy the standard.

A clean scope boundary, maintained with some discipline, is the difference between an IMS that a small team can run and an IMS that consumes more overhead than running two separate systems would have.

The dual surveillance audit experience

We used the same certification body for both standards, which made the surveillance audit process significantly simpler. The auditor team — two people with competence across both standards — conducted a combined surveillance audit over two days. Day one covered ISO 9001 clause coverage, operational process sampling, and customer satisfaction evidence. Day two covered ISO 27001, including Annex A control sampling, incident management evidence, and access control reviews.

The efficiency gains were real: a single opening meeting, a single closing meeting, shared document reviews, and an audit report that addressed both certifications in a unified findings format. The audit team found no confusion from the integrated documentation structure — if anything, the consistent document format across both standards made the evidence trail easier to follow than separate systems with different naming conventions would have.

The combined system costs more to build initially than either standard alone — the integration design work, the combined auditor training, the unified document architecture — but less to operate. In year three of the certification, with the system mature and the auditor pool experienced, the compliance overhead is a fraction of what parallel systems would require. That payoff curve is worth understanding before you start, because the first year will not feel like it's going well.