Manufacturing vs IT company: where ISO 27001 actually differs

Two types of company side by side: one table to see where the paths split

Start with the whole picture. The way to use this table is not to memorise it, but to hold it against your own company: whichever column describes you more closely is where the preparation weight belongs. In reality plenty of companies are hybrids (a manufacturing company with its own software team, an IT company with hardware and a production line); a hybrid has to judge row by row rather than copy a whole column.

1. Information assets: where the inventory starts

This is the source of the fork, and also where many projects go crooked. ISO/IEC 27001 is driven by asset — threat — vulnerability — risk — control; get the asset inventory wrong and everything after it is wrong.

Manufacturing: the assets are not in the IT department's hands

If a manufacturing company's asset inventory lists only servers, computers and network equipment, it is close to not having been done. The things that actually need protecting are largely outside the server room:

• Product and process: product drawings and 3D models, BOM, routings and process sheets, recipes and mixing ratios, key operation parameters (temperature, pressure, speed, time), mould drawings, CNC machining programs and robot teach programs, inspection and test data, failure analysis records.
• Customer and technical origin: technical documents and drawings supplied by customers (usually under an NDA), prototype parts and samples, complaint and recall records, tender and quotation documents.
• Systems: ERP, MES, PLM/PDM, WMS, QMS, as well as SCADA, PLCs, HMIs, industrial PCs, edge gateways, and the systems embedded in CNC and inspection equipment.
• Media and locations: paper drawings and process sheets, the archive room and drawing cabinets, removable drives and USB sticks, shop-floor terminals and Andon boards, printers and copiers, retired equipment and hard disks.

The key word is ownership. In an IT company, "assets sit with the IT department" is normal; in a manufacturing company, drawings belong to R&D, process parameters to process, programs to equipment or process, inspection data to quality, customer technical documents possibly to sales or quality, and IT owns only servers, network and office endpoints. The asset owner must be written as a post in a business department, not "managed on behalf of by IT" — otherwise the risk treatment never lands on a person, and one question of "who executes this measure" exposes it during the audit.

IT: an inventory that is easy to make "complete and useless"

Much of an IT company's asset estate can be exported from systems, so compiling the list is not hard; what is hard is whether the list can support a judgement. Code repositories, branches and artefact repositories, production databases, object storage, cloud hosts and snapshots, keys and configurations, the log platform, monitoring and alerting, collaboration tools (messaging, email, file sharing), test data — all of these need to be on the register.

Two difficulties are specific to IT companies. The first is the boundary of customer data — when processing customer data on a client's behalf, you must be able to state, for each customer, "where the data is stored, which systems it passes through, who can access it, how it is deleted at expiry or exit, and how deletion is demonstrated". The second is shared responsibility — for services running in the cloud, the underlying infrastructure is the provider's responsibility while configuration and access are yours; the inventory has to draw that line, or the risk treatment will read "the cloud provider is responsible for this", which is the same as writing nothing.

2. Risk assessment: where the threats come from

The same act of "identifying threats and vulnerabilities" faces threat sources that barely overlap between the two types of company. In a manufacturing company's risk scenarios, hackers are often not the main character; in an IT company's risk scenarios, the shop floor and paper documents hardly appear at all.

Manufacturing: people, equipment, outsourcing

Information security incidents that actually happen in manufacturing companies look like this:

• A new product is prototyped and the full drawing set is sent to the mould shop, which forwards it to the next-tier machining plant, and the drawings reach a competitor;
• A process engineer leaves, taking the set-up parameters and their own process notes, and reuses them directly at a competitor;
• The shop floor uses a USB stick to copy programs between several machines; one of them had been plugged into an internet-connected PC, ransomware gets onto an industrial PC, and a line is down for two days;
• The equipment vendor's remote maintenance channel stays open all year round once the contract is signed, and nobody records who connected and when;
• Paper process sheets are taped beside the machine, and visitors, external contractors and cleaning staff can all photograph them;
• An old industrial PC runs an operating system long out of support, cannot take security software or patches, and nobody dares to reboot it.

So a manufacturing risk assessment is better laid out by "product line × stage" than by department. The stages are usually: quotation and bidding → prototyping and trial production → mass production → outsourcing and subcontract machining → inspection and shipment → after-sales and claims. At each stage ask only three questions: what information leaves the site, leaves the system, or leaves controlled people here? The answers are the risk scenarios; controls come afterwards.

One more point has to be settled in advance: what to do with equipment that cannot be changed. The risk of a retrofit shutdown is sometimes higher than the information security risk, and the company will keep the old system. In a management system this cannot be closed by writing "not applicable"; it has to be written as compensating measures: network isolation and one-way data extraction, dedicated whitelisted USB sticks, read-only operation at the device, physical locks and key control, out-of-band traffic monitoring, a dedicated inspection route and an escalation path for anomalies. Compensating measures are controls too, as long as they can be executed and recorded.

IT: attacks, excess privilege, supply chain and configuration

An IT company's risk scenarios look more like this: external attack and credential stuffing, insiders reading customer data beyond their rights, known vulnerabilities introduced by open source components, repository access not revoked when an outsourced developer leaves, a cloud object store configured for public read, keys committed to a code repository, logging switched on but nobody watching it, production data used in a test environment. The unit of risk is "system and data flow", not department: from ingestion to processing, storage, backup and destruction, every segment needs the question of who can touch it.

Cloud-hosted services need one more layer: write the risk down at the configuration level. "The cloud platform is not secure" is not a risk that can be treated; "a certain bucket allows anonymous reads", "the management port of a certain cloud host is open to the internet", "key rotation has no owner" are. The more specific the wording, the more the treatment can land, and the better it holds up in the audit.

3. Access control and accounts: managing posts or identities

Access control is a section where the two types of company feel the difference strongly: in practice access control is designed around identities and systems in an IT company, and around posts and entry points in a manufacturing company — cover only one half and the other half stays empty.

Manufacturing: from post permissions to shop-floor doors

The accounts and permissions a manufacturing company has to manage go well beyond "domain accounts":

• Business system accounts: purchase and customer prices in ERP, work orders and reporting in MES, drawing downloads in PLM, stock adjustments in WMS — these permissions are no less sensitive than IT systems;
• Equipment operation rights: operator, set-up technician and engineer often correspond to different parameter change rights, and on many machines this is done with a panel password or a key switch rather than an account;
• Program transfer rights: who may transfer a machining program to the machine, who may change it, and who reviews the change;
• Files and drawings: folder permissions for drawings on shared drives, the lending register for paper drawings, the keys to the drawing cabinet;
• Physical entry: site access doors, zoning of workshop and warehouse, the drawing room, the room holding servers and network cabinets, visitors and external contractors.

Three specific points go wrong easily in manufacturing: high frontline turnover, with the account not disabled and the access card not collected on the day someone leaves; shared accounts, where one terminal in the workshop uses one account for the whole shift and nobody can be traced when something happens; permissions that follow the person, where set-up rights are granted and never taken back. None of the three is hard to fix, but all three need production involved — IT alone cannot push them through.

IT: the whole line from onboarding to offboarding

Access control in an IT company centres on the identity lifecycle and privileged paths: access created at onboarding, adjusted on transfer, revoked on the day of leaving, with a basis and a record at every step; production access going through approval, a jump host or bastion, with session records; keys and credentials managed centrally and never in code or in chat tools; multi-factor authentication on admin consoles and cloud consoles; outsourced and third-party developers authorised by project and revoked when the project ends; and access to customer data describable per customer as "who looked at it and when".

The common gap in IT companies is not "no policy" but revocation that is too slow and shared privileged accounts: the exit approval is processed while accounts on several systems are still open; operations share one administrator account for convenience. Both are easy to find in an on-site sample — the auditor only has to hold the leavers list against the system user list.

4. Suppliers and outsourcing: drawings going out, or data going into someone else's system

Both types of company manage suppliers and outsourcing, but the shape of the risk is reversed: a manufacturing company fears something being taken out, an IT company fears data going into someone else's system.

Manufacturing: an asymmetric outsourcing chain

A manufacturing company's external parties form a long list: mould shops, subcontract machining, surface treatment, testing and calibration bodies, equipment vendors and agents, consumable and spare part suppliers, logistics, scrap recycling, IT operations and software providers, on-site contractors, cleaning and security. The characteristic of this chain is information asymmetry — what you hand over is a complete drawing set, while the other party has taken on a single operation; you ask for confidentiality, and the other party may never have signed an NDA in its life.

What is needed is not to make suppliers "do an ISO 27001 as well", but to control the information flow:

• Signed: the NDA covers drawings, process, recipes and customer technical documents, and states clearly that no further subcontracting and no retention are allowed, and that material is returned or destroyed at expiry;
• Sent, but not in full: provide only the views or dimensions that operation needs, and remove structures and parameters unrelated to the machining; number prototype parts so that who received them can be traced;
• Recorded: keep a register of outbound releases — date, recipient, document and version, purpose, whether returned or destroyed, and the person who handled it. This register carries real weight in an audit, because it proves both that the risk was identified and that the measure is being executed;
• Controlled on site: vendor remote maintenance is requested, time-boxed, attended and recorded; on-site and construction staff are registered, given temporary access, limited to defined areas, and told clearly that photography is not allowed;
• Recovered: retired equipment, industrial PCs, hard disks and copier storage media need a data erasure record before disposal; whole machines must not be sold on to a recycler as they are.

Writing these requirements into the purchasing contract and the annual supplier evaluation form is the lower-effort way to make them land. Add four columns to the evaluation form: whether the NDA is valid, whether the outbound register is complete, whether on-site behaviour complied, and whether the incident notification deadline is defined. One evaluation then serves two purposes, procurement and the management system.

IT: SaaS and cloud are the main external dependencies

An IT company's external dependencies are more concentrated and less visible: cloud providers, SaaS tools (collaboration, monitoring, code hosting, customer support, HR), open source components, outsourced development teams, and a variety of "just trying it out" tool accounts. The risk points are where the data went, who can still access it, and whether you can get it back when you leave.

• Supplier tiering: three tiers by "can it touch customer data" — those that can touch customer data, those that only provide tools without hosting customer data, and those that only supply office goods. The tier decides assessment depth and review frequency; not every supplier needs the same form;
• Agreements and location: for those that can touch customer data, sign a data processing agreement stating storage location, sub-processors, incident notification, and export and deletion at exit;
• A maintained inventory: a list of SaaS and cloud services stating who uses each one, what data it holds, who the administrator is, and how accounts are opened and closed. This list is often missing, yet it is exactly the basis on which an audit judges whether you know where your own data is;
• Open source and outsourcing: component inventories and vulnerability tracking need an owner; outsourced development needs agreed code delivery, permission scope, and repository and account recovery at the end; test data given to outsourcers must be masked rather than copied straight from the production database.

5. Business continuity and downtime: the line stops, or the service stops

"Availability" is one word in the standard and two completely different things in the two types of company. This section is easy to write as a generic template, and easy to be questioned apart during the audit.

Manufacturing: downtime means a stopped line, a scrapped batch, a breached delivery

If a manufacturing company's business continuity plan says only "switch to the standby server when the server fails", it has not covered the main subject. What has to be written down is how the business keeps running while the system is unavailable:

• Degraded mode: when MES or ERP is down, how work orders are issued, how reporting is recorded, how material issue is checked, how shipment is released — the paper forms need numbers, signatures and a defined way of being entered afterwards, all settled in advance and rehearsed once;
• Recovery on the equipment side: where the backups of PLC programs, HMI screens, machine parameters, robot programs and equipment configurations are, how often they are taken, who can restore them and how long a restore takes; which items on the spare parts list are critical;
• Sequence and takt: recovery objectives are set by the production takt and shift pattern, not a number picked by IT. Which line comes back first, which machine can be routed around, which operations have work-in-progress buffers — that is production's information;
• The trade-off of cutting the network: during a security incident, isolating the production network often also stops the line. Who has the authority to decide, under what conditions, and how the site is organised afterwards must be settled in advance, not debated on the day of the incident;
• Network segmentation: separating the office network, the production network and the device network limits the attack surface, and also makes "partial isolation" an option instead of a plant-wide standstill.

IT: downtime means an unavailable service, a breached SLA

An IT company's continuity is organised around the service: which components the service depends on, what level of degradation each component's failure causes, what the failover and rollback actions are, and how customers are notified. Be specific about: the failover path when a cloud region or availability zone fails; what to do when "overlooked dependencies" such as the domain, certificates, object storage and message queues fail; how to roll back a bad release and who decides; whether backups are recoverable (verify, do not just read the job status); whether the recovery objectives of key services match what was agreed with customers. ISO 20000 looks at the same thing from the service catalogue and SLA side, and a company running both systems can share the drill records.

One more thing IT companies miss easily: continuity depends not only on architecture but on people. If only one person can perform a key operation, that person's holiday or departure is a single point of failure. Duty rosters, handover documents and dual review are continuity measures, not an HR arrangement.

6. People and awareness: a shift briefing or a phishing drill

Awareness is a section where the two types of company diverge a great deal. A frontline employee in a manufacturing company may not open a computer once in a year, and sitting them in a meeting room for a slide deck on information security produces close to nothing; IT company staff work in systems all day, and for them concepts matter less than constraints.

Manufacturing: translate requirements into actions

Awareness work in a manufacturing company has to land on concrete actions, and in the places where people actually stand:

• By post, not for everyone at once: R&D on sending drawings out and on versions; process on parameter changes and backups; equipment maintenance on program transfer and attending remote sessions; quality on customer technical documents and inspection data; warehouse on documents and permissions; sales on quotations and customer information;
• Short, frequent, on site: one point at the shift briefing works better than a two-hour session. Make it concrete: "drawings must not be photographed", "an unknown USB stick must not go into a machine", "parameters must not be changed without authorisation", "a visitor in the workshop must be accompanied";
• Cover the non-standard people: new joiners, transfers, on-site subcontractors, construction workers, cleaning and security — they can enter sensitive areas and are often not on the training list;
• Signage on site: notices beside machines, at the drawing room, at access doors and in the print area are seen far more often than the policy document;
• Handover on exit: paper documents, drawings, badges, access cards, USB sticks and laptops are collected item by item and registered.

IT: talk about behaviour that can be checked

Awareness work in an IT company can be more engineered: code and keys are not passed outside, production data is not carried out, customer data is not pasted into external tools (including the various AI assistants), unknown links and attachments, environment requirements for remote and home working, the permission boundary for third parties and outsourcers, and the offboarding checklist. Training needs records: who, when, what was covered, and how it was verified (a short quiz, a drill, a simulated phishing run). Do not report only "how many people clicked" — look at whether anyone reported it afterwards; that is the evidence that the system is working.

7. Where an audit interview tends to push

The audit logic is the same: follow asset — risk — control — record along one chain and see whether it runs all the way through. But what gets pulled out is completely different between the two types of company.

What manufacturing companies get pushed on

• Is there a register for drawings sent out? Which version did the mould shop receive? How do you confirm it was not passed to the next tier?
• Whose account is this terminal in the workshop? Three people share it — how do you assign responsibility?
• Who may change machine parameters? Is the change reviewed? When was it last changed, and why?
• When did the equipment vendor last connect remotely, who approved it, and was anyone present?
• Why is this industrial PC still running an unsupported system? What are the compensating measures, and who inspects it?
• With the network down or MES unavailable, how does the line start? How are the paper records entered afterwards? Has it been drilled?
• Where are paper drawings kept, who may take them, and where is the lending register? How are obsolete drawings and retired hard disks disposed of?
• If a subcontractor has an information security incident, how soon must it notify you? In which agreement is that deadline written?

What IT companies get pushed on

• Where is a given customer's data stored, which systems does it pass through, and who can access it? On exit, how is it deleted and how is that demonstrated?
• In a multi-tenant environment, how is isolation implemented? Is there any test or verification record?
• Take a leavers list and check the accounts on the spot: which are still open, and why?
• Who can connect directly to the production database? Does it go through approval, and are sessions recorded?
• Where are keys and credentials kept? Search the code repository for hard-coded ones.
• Which SaaS tools are in use, who maintains that list, and what data do they hold?
• When was the last recovery drill, what was restored, and how long did it take?
• How long are logs retained, who reads them, and is there a record of alert response?

The skeleton both types of company share

Having set out the differences, the shared part has to be stated too — it does not need to be rebuilt per industry, and would not fail because the industry is different.

The framework the standard requires is one set: policy and objectives, certification scope and sites, roles, responsibilities and authorities, risk assessment and risk treatment (including the statement of applicability), documented information and record control, competence and awareness, operational control, monitoring and measurement, internal audit, management review, nonconformity and corrective action, continual improvement. The certification process is one path as well: gap analysis → risk assessment → system build → operation and record accumulation → internal audit and management review → Stage 1 document review → Stage 2 on-site audit → certification, then one surveillance audit a year, a 3-year certificate term, and recertification before expiry.

Three kinds of content can be shared outright:

• The document skeleton: the four-layer structure of manual, procedures, work instructions and record forms, with numbering rules, approval, distribution, version control and retention periods;
• Management actions: internal audit plans and checklists, nonconformity reports and corrective action verification, management review inputs, outputs and minutes, corrective action tracking;
• Generic controls: awareness and training, supplier files and evaluation, incident and problem handling, change management, and how continuity drills are organised.

What cannot be shared is only the professional core: the drawing and process assets, OT assets and device-side controls, and the outsourced information flow of a manufacturing company; the code and data flows, cloud and tenant boundaries, and identities and keys of an IT company. In other words, the skeleton is the same; the assets, scenarios and evidence filled into it are not. A company that already holds ISO 9001 has a clear advantage here — document control, internal audit and management review are already running, so an ISO 27001 project mainly adds the information-security-specific parts and the workload is much smaller; but the risk assessment, the statement of applicability and the security controls must be built anew — quality system documents cannot be used in their place.

An IT company also running ISO 20000 can merge documents, internal audit, management review, training and supplier evaluation further still; that is set out in full in ISO 27001 + ISO 20000 together: where the saving comes from. For what each audit stage looks at, see ISO 27001/20000 audit stages, one by one.

Common misconceptions: one "assumption" on each side

Manufacturing: assuming "IT can handle it". This is one of the costlier misjudgements in manufacturing projects. IT can manage servers, networks, office endpoints and some system accounts, but it cannot manage how R&D releases drawings, how process changes parameters, shared accounts on the shop floor, program transfer onto equipment, customer technical documents held by quality, or the subcontracting register held by procurement. The result is a set of documents written neatly, and on site R&D says it never heard of it, process says parameters have always been changed that way, and the workshop says it cannot work without USB sticks. ISO/IEC 27001 is not an IT project; it is a governance project for the business's information assets, in which IT is one of the executing parties. What is really needed is a lead who can move people across departments, plus a contact in each of R&D, process, production, quality, equipment and procurement.

IT: assuming "no server room means no physical security". Without a self-built data centre, the physical and environmental part does not disappear; it simply moves: office access control and visitors, desk locks and screen locks, whiteboards and printouts, laptops in courier packages and on business trips, the working environment at employees' homes, service work at customer sites, retired computers and hard disks — and the cloud provider's data centre, which the provider operates but where you still have to be able to explain which layer of physical control you selected and on what basis. Treating "we are in the cloud" as the answer on physical security usually runs out of answers in the interview.

A few more misconceptions common to both sides:

• Copying a template. The documents describe assets and processes that belong to another industry, and it shows at a glance that they were not written here. A management system can be referenced, but not copied;
• Turning ISO 27001 into "buying equipment". Firewalls, encryption, backup and endpoint protection are means; the audit looks at whether those means correspond to a risk judgement, whether someone is executing them, and whether there is a record;
• Confusing ISO 27001 with occupational safety. Information security covers confidentiality, integrity and availability of information and does not replace the management of personal and production safety; the two systems can support each other, but their conclusions cannot stand in for each other;
• Writing the scope larger or smaller than reality. Written larger, the departments and sites not covered become blanks; written smaller, the business the customer asked about is not covered. Once the scope changes, assets, risks, documents and records all have to change with it, and the later it changes the more it costs;
• Stopping at the certificate. The annual surveillance audit looks at whether that year's records are continuous. Without day-to-day accumulation, the rush before the audit produces dates and content that are hard to align.

Action list: do the shared part first, the fork second

The list below is ordered "shared first, fork second". The way to use it: do the items marked [Shared] first, then work through the [Manufacturing] or [IT] block for your own industry. Hybrid companies need both blocks, ordered by the share of business.

• ⬜SharedFix the scope: write in one sentence which business, departments and sites the certification covers, and confirm for each "there are people, there are records, there are system traces"
• ⬜SharedFix the people: one lead who can move people across departments, plus contacts in R&D / process / production / quality / equipment / procurement (or R&D / delivery / operations / sales), written down
• ⬜SharedTake stock of assets: compile the inventory in layers, with a business owner (post), a storage location and the three consequences for each entry
• ⬜SharedRun the assessment: lay out risk by scenario, and output "what will be treated, what the treated state is, who finishes it when"
• ⬜SharedRun one cycle: operate the system and accumulate records; run one internal audit and one management review, with real findings and verified corrective action
• ⬜ManufacturingOutbound register: for every drawing and process document released — recipient, version, purpose, return or destruction — item by item traceable
• ⬜ManufacturingPost matrix: system and equipment permissions set by post, signed off by production and process, revoked together on exit and transfer
• ⬜ManufacturingOT status: list the equipment that cannot be patched or stopped, and write compensating measures and an inspection owner for each
• ⬜ManufacturingDegraded mode and recovery: drill the paper process once for system unavailability; drill restore of equipment programs and parameters once, recording elapsed time
• ⬜ManufacturingSubcontracting and remote access: NDAs, remote maintenance approval and attendance, on-site and construction management, erasure of retired media — all four need records
• ⬜ITData map: draw one line for customer data from ingestion to deletion, marking storage location, who accesses it, and how deletion is demonstrated
• ⬜ITIdentity sampling: check the leavers list against system accounts, and the privileged account list against who actually uses them; both have to line up
• ⬜ITCloud and keys: sweep for publicly readable storage, management ports open to the internet, and hard-coded credentials in code
• ⬜ITSaaS inventory: who uses each tool, what data it holds, who the administrator is, how accounts are closed — and name the person who maintains it
• ⬜ITRecovery verification: restore one key service for real and record the elapsed time; drill one release rollback
• ⬜SharedSelf-test: walk three chains for your own industry — where a chain does not run through is where the audit will ask
• ⬜SharedAsk the body: scope, sites, the basis for headcount and audit arrangements are subject to the certification body's assessment and the standard version currently in force

Putting the two types of company side by side, the conclusion is plain: ISO 27001 never checks whether you own a set of information security documents, but whether you know where your information is, who is touching it, and whether you can hold things together when something goes wrong. An IT company answering those three questions finds the answers largely inside systems; a manufacturing company answering the same three questions finds half the answer inside systems and half on the shop floor. Work out which one you are, and the preparation will not start from the wrong asset inventory, and will not be stopped on site by a single "so who actually does this".

▍Not sure how to draw your own asset boundary? Leave a comment noting "industry comparison", send us your main business, organisation size and main sites, and we will send back an asset inventory framework and a scenario question set for your industry.