Data Security in Contract Manufacturing: The Shared Responsibility Model in the OEM-EMS Relationship

Outsourcing production today means entrusting a partner with something far more valuable than a simple assembly order. The OEM hands over complete design documentation, Gerber files, bills of materials (BOM), firmware, test results and often the commercial and personal data of its own customers. The moment this information leaves the client's servers, data security stops being the concern of a single organisation — it becomes a responsibility shared by both parties. This article explains what the shared responsibility model in the OEM-EMS relationship actually is, how to divide the obligations between partners, and how to build an arrangement that withstands both a ransomware attack and a NIS2 compliance audit. We also illustrate it with the practices applied at Assel.

Table of contents

1. Why data security has become a criterion for choosing an EMS partner
2. What the shared responsibility model in the OEM-EMS relationship is
3. A map of information assets in an EMS project — what exactly are we protecting
4. The threat landscape backed by research
5. The regulatory framework: NIS2, the KSC Act, GDPR and ISO standards
6. The responsibility matrix: who is accountable for what
7. The shared responsibility model in practice: Assel's approach
8. Case study: a project from the security industry
9. The organisational and legal layer: contracts, NDAs and audits
10. Due diligence: how to verify an EMS partner
11. Implementing the shared responsibility model step by step
12. Security across the entire product lifecycle
13. Conclusion
14. Frequently asked questions (FAQ)

Why data security has become a criterion for choosing an EMS partner

For years the key criteria for selecting a contract electronics manufacturing provider were price, quality and on-time delivery. Today a fourth, equally important criterion has joined the list: maturity in information security. This shift is not a matter of fashion but of hard data.

According to the IBM "Cost of a Data Breach 2024" report, the average cost of a data breach in the industrial sector reached USD 5.56 million — 18% more than a year earlier, making industry the third most financially exposed of the seventeen sectors studied and placing it 13% above the global average (USD 4.88 million)^[1]. The manufacturing sector also stands out in response time: it takes an average of 199 days to identify a breach and a further 73 days to contain it. In a production environment, every hour of unplanned downtime — for example due to a ransomware attack — can cost a plant, depending on the industry, up to USD 125,000^[2]. These are figures that turn security from a cost item into a hard business argument.

For an OEM this means one thing: choosing a contract manufacturing partner also means choosing the level of risk the entire organisation takes on. The weakest link in the supply chain is not only one's own infrastructure but every entity entrusted with data. Conversely, a mature EMS partner can shoulder that responsibility and turn it into a competitive advantage. It is no coincidence that more and more clients, already at the onboarding stage, run security audits at their suppliers or send out detailed security questionnaires — a practice we see regularly at Assel.

What the shared responsibility model in the OEM-EMS relationship is

The concept of the *shared responsibility model* is best known from cloud computing, where the infrastructure provider is responsible for the security "of the cloud" and the client for security "in the cloud". The same logic describes the OEM-EMS relationship perfectly, even though in manufacturing practice it is formalised far less often.

In the OEM-EMS shared responsibility model, both parties divide control over different layers of information protection but — crucially — no layer is left unowned. The OEM remains the owner of the intellectual property and defines what constitutes a trade secret and how data should be classified. The EMS partner is responsible for the operational security of the environment in which that data is processed: network segmentation, access control on the production floor, protection of the workstations that drive the SMT lines, and the way documentation is stored.

The essence of the model is not to shift risk onto the other party but to divide it consciously and in a documented way. The most dangerous security gaps arise not where one party has failed, but where both parties assumed the other was responsible for a given area. A good example is firmware loaded on the production line: the OEM assumes the EMS secures the programming stations, the EMS assumes the OEM supplies digitally signed images — while in reality no one checks the integrity of the file between one step and the next. The shared responsibility model eliminates precisely these "grey zones". It is worth stressing that in practice this division stems above all from the requirements defined by the client, to which the EMS partner adapts — the client retains the full picture of security, and its requirements determine the scope of each party's responsibility. It rarely takes the form of a single, meticulously written document; more often it is the sum of the requirements agreed with the client, which the partner consistently implements.

A map of information assets in an EMS project — what exactly are we protecting

Before dividing responsibility, the subject of protection must be defined precisely. In a typical contract electronics manufacturing project, several categories of sensitive information assets pass through the EMS partner's hands, each carrying a different risk profile.

The first category is design and engineering documentation: schematics, Gerber files, CAD/CAM data, mechanical drawings and specifications. This is the core of the product's intellectual property — a leak makes it possible to reconstruct the design for a competitor or to run unauthorised parallel production.

The second category is the bill of materials (BOM) together with supplier data and component purchase prices. Disclosure of the BOM means not only the loss of a technological secret but also the exposure of the cost structure and commercial relationships of the producer.

The third, often underestimated, category is firmware and embedded software. Code loaded during production is both valuable intellectual property and a potential attack vector — unauthorised modification of a firmware image on the line can introduce a backdoor into the finished device.

The fourth category is production and test data: process parameters, functional and in-circuit test results, yield and defect data. These allow process and quality know-how to be reconstructed.

The fifth category, relevant mainly in the MedTech, industrial and energy sectors, may be personal data and regulated data. Its protection is subject to the GDPR and sector-specific rules, and responsibility for it is shared under processing-entrustment arrangements. In practice a mature EMS partner often does not hold such data at all — Assel, for example, does not process patient data in any of the products it manufactures, which is why this case remains excluded from the scope of its ISO 13485 certification.

An effective shared responsibility model begins with a joint classification of these assets and the assignment of a confidentiality level to each. Only on that basis can one meaningfully define who stores the data, how, and for how long, and who is responsible for securing it at each stage.

The threat landscape backed by research

Dividing responsibility only makes sense when it responds to real threats. The modern electronics supply chain is attacked on several fronts at once, and research from recent years helps to structure them.

Supply chain attacks are among the fastest-growing categories of threat. In its "Threat Landscape" reports, the European Union Agency for Cybersecurity (ENISA)^[3] consistently identifies the supply chain as one of the key vectors, highlighting the growing share of state-sponsored attacks and the fact that compromising a single supplier lets an attacker reach many organisations at once. In the OEM-EMS model this means an attacker does not have to break the defences of a well-protected OEM — it is enough to find a gap at any of its partners or subcontractors.

A distinct class of risk, well documented in the academic literature, is counterfeit electronics and hardware Trojans. Work published in IEEE journals and on ScienceDirect^[4], among others, analyses how malicious implants can be introduced into printed circuit boards at various stages of the supply chain and how difficult they are to detect after the fact. For the OEM-EMS relationship the conclusion is clear: control of component authenticity and provenance — which is distinct from traceability (the tracking of a product's flow through production) — together with trusted supply channels, is an integral part of data security, not a separate logistics issue — a falsified integrated circuit is also a potential gateway for information leaking from the finished device.

The third front is ransomware and threats to the OT (operational technology) environment. Unlike classic IT, in a production environment an attack does not end with data theft — it halts lines, disables machines and generates the downtime costs of up to USD 125,000 per hour mentioned above. The convergence of IT and OT networks, driven by the idea of Industry 4.0, widens the attack surface: systems once isolated from the internet are now sometimes connected to corporate networks.

Finally, the human factor and insider threats cannot be ignored. IBM data show that in the industrial sector 47% of breaches are due to deliberate attacks, but as much as 27% are human error and 26% system failures^[5]. This means that more than half of incidents have a root cause that can be prevented through good procedures, training and access control — not solely through advanced technology.

The regulatory framework: NIS2, the KSC Act, GDPR and ISO standards

The shared responsibility model does not operate in a legal vacuum. Over recent years, EU and national regulations have transformed supply chain security from good practice into a hard obligation whose neglect carries severe penalties.

The NIS2 Directive and Poland's National Cybersecurity System Act

The NIS2 Directive, transposed into Polish law through the amendment to the National Cybersecurity System Act (KSC), extends responsibility for cybersecurity across the entire supply chain. Entities classified as "essential" or "important" — and many manufacturing companies fall into these categories — must identify their significant suppliers, assess the associated risk and demonstrate structured management of that risk.

In practice this means an obligation to build supply chain security policies, conduct supplier due diligence, and include in contracts audit rights, subcontractor rules and incident-reporting obligations. Importantly, responsibility rests personally with the management body — members of management remain accountable for compliance even when they delegate tasks. Supply chain security thus becomes a board-level matter.

The scale of potential sanctions is significant: for essential entities fines can reach EUR 10 million or 2% of annual turnover, for important entities EUR 7 million or 1.4% of turnover^[6], and managers may face individual penalties. The new rules also set specific deadlines for implementing information security management systems and for periodic cybersecurity audits. For the OEM-EMS relationship this regulation is a turning point: a producer who, as an essential entity, is responsible for its suppliers must be sure that its EMS partner meets adequate standards — and an EMS partner able to document this becomes the natural choice.

GDPR and the entrustment of data processing

Where personal data is involved, the OEM-EMS relationship may take the form of processing entrustment within the meaning of the GDPR. The producer usually acts as the data controller and the EMS partner as the processor, acting on the documented instructions of the controller. This requires a data processing agreement (DPA), a defined scope and purpose of processing, and adequate technical and organisational measures. In practice, a mature EMS partner seeks to minimise the processing of the client's personal data — limiting it to the necessary project communication — and treats concluding a DPA as part of the arrangements for a specific project. This is a textbook example of shared responsibility, in which the scope of each party's obligations follows directly from the law and the contract.

ISO standards and industry norms as a language of shared responsibility

Management systems based on ISO standards provide a common, measurable language in which both parties can describe the division of duties. ISO/IEC 27001 defines an information security management system (ISMS) and is today the de facto standard that OEMs expect from mature EMS partners. It is complemented by industry standards: ISO 9001 (quality management), ISO 13485 (medical devices, where data protection and traceability have a regulatory dimension) and ISO 14001 (environment). Resilience to downtime is described in turn by the ISO 22301 business continuity standard, whose methodology remains a valuable reference regardless of the status of the certificate itself. In the assembly domain, standards such as IPC-A-610 organise the quality requirements that indirectly support traceability and process control.

An EMS partner with a mature set of management systems provides the OEM with auditable evidence of process maturity, which radically simplifies meeting NIS2 obligations. Assel operates on the basis of ISO 9001, ISO 13485 and ISO 14001 certificates, maintains a business continuity plan aligned with the ISO 22301 methodology, and the implementation of an information security management system compliant with ISO/IEC 27001 is in its final phase — with a proposed scope covering "contract manufacturing services for electronic and electromechanical products".

The responsibility matrix: who is accountable for what

At the heart of the shared responsibility model is a clear division of tasks. The matrix below organises the typical allocation of duties between the OEM and the EMS partner. In practice every project requires individual tailoring, but the arrangement below is a starting point.

The OEM's responsibility covers above all: determining which information constitutes a trade secret and how it should be classified; delivering documentation securely and to the minimum necessary extent (the need-to-know principle); digitally signing firmware and transferring images in a verifiable way; defining security requirements in the contract and specification; and periodically auditing the partner. The OEM remains the owner of strategic risk and decides on the level of protection appropriate to the value of the product. It is worth stressing that oversight of the client's documentation itself remains with the client — the EMS partner supervises its own documentation and the process of introducing changes to the documentation entrusted to it.

The EMS partner's responsibility covers in turn: the operational security of the environment in which data is processed; segmentation of IT and OT networks and isolation of production stations; control of physical access to the floor and logical access to systems; secure storage and destruction of documentation in line with the agreed retention; management of subcontractors and control of their access to data; component traceability; and incident response and reporting to the client within an agreed time.

Shared areas — requiring joint agreement of both parties — include, among others: classification of information assets, the change management procedure, the incident response plan (who informs whom and within what time), the rules for destroying data at the end of the project, and business continuity exercises. It is precisely in the shared areas that the most dangerous "grey zones" arise, which is why they must be described in the greatest detail.

A practical tool for formalising this division is a RACI matrix (Responsible, Accountable, Consulted, Informed) agreed jointly when the cooperation is set up, based on the client's requirements, before NPI begins. Such a document eliminates guesswork and later becomes the basis for audit.

The shared responsibility model in practice: Assel's approach

Theory gains value only when it translates into everyday processes. Below we show how the individual layers of the shared responsibility model look in practice at Assel — not as a list of declarations, but as concrete operational mechanisms.

Secure transfer and storage of documentation

The starting point is the way project documentation reaches the partner. Assel provides clients with a dedicated cloud channel for transferring specifications, so that sensitive files do not have to travel by unsecured routes. On the EMS side, documentation is moved to disk resources with restricted access granted on a need-to-know basis. Only the departments that genuinely need it for the early analysis of an enquiry and for delivery — engineering, sales, quotations and the strategic team — have insight into the specification. This role-based access model limits the circle of people coming into contact with the client's intellectual property to the necessary minimum.

Network segmentation and physical security

The technical environment is built on the separation of network zones. The office network is separated from the network in which the production machines operate, and guest traffic is handled by a dedicated visitor network. As a result, compromising one zone does not automatically open access to the others.

The digital layer is complemented by extensive physical security. Access to rooms is controlled by electronic readers, and permissions are assigned to groups of people only for the zones a given group should be able to enter. The facility and its grounds are covered by CCTV, and the whole is protected by a professional security company on a 24/7 basis. This is the practical fulfilment of the principle that data security begins at the door to the floor.

Firmware protection — three models of cooperation

Firmware is one of the most sensitive elements of a project, so the way it is protected is agreed individually with the client and depends on the design of the programming process. In practice Assel runs projects in three variants that perfectly illustrate the idea of shared responsibility. In the first, firmware is loaded directly into the device from the client's external network, and the EMS partner has no access to it — full control remains with the OEM. In the second, programming is carried out from dedicated media, which are strictly controlled and, after use, stored in locked cabinets. In the third, firmware resides on test equipment, and the level of protection follows from the way the client has constructed those stations. In each variant the boundary of responsibility is clearly drawn — and that is the crux of the model.

Volume control and traceability — protection against overproduction

One of the most common concerns of OEMs is the risk of production "on the side" — manufacturing units beyond the ordered volume. Assel addresses this on several levels. An MES-class system supervises every manufactured unit, and assembled products are reported on that basis. Order quantities are set for a specific order and production begins for exactly that quantity. Wherever the design of the PCBA or product allows, each unit receives an individual serial number, ensuring full traceability. This is complemented by a continuous inventory process in which the consistency of the quantity of material returned after production is verified. This set of mechanisms means any discrepancy between the material issued, the number of units produced and the order is quickly detected.

The data lifecycle: retention, return and deletion

Responsibility for data does not end with the last unit produced. Assel applies a retention policy that varies according to the type of document, and where there are individual arrangements with the client, selected data may be stored under separate rules tailored to the project. The client may request the return or deletion of documentation — a matter of agreement that can be confirmed formally. As a result, intellectual property does not "live" in the partner's environment longer than necessary.

Incident response, business continuity and governance

The breach-reporting procedure is defined on two levels: on the one hand it stems from legal requirements — the NIS2 Directive and the amendment to the KSC Act based on it — and on the other it is subject to agreement with the client as to the scope and timing of notification of an incident concerning its data. Business continuity is based on a plan aligned with the ISO 22301 methodology, whose way of working is maintained operationally. Governance of information security and GDPR compliance rests with a clearly assigned structure: internal coordination is led by a designated managerial role, while responsibility for external communication, including relations with the supervisory authority (the data protection authority), rests with the management board — consistent with the spirit of NIS2, which moves responsibility for cybersecurity to the highest level of management.

Subcontractors and the boundaries of the process

The principle of passing confidentiality and security requirements down to subcontractors is mandatory in the shared responsibility model. In Assel's case, however, an important fact is worth noting: processes related to the assembly of electronic devices are carried out in-house and are not delegated externally, which simplifies the chain of responsibility. Where a given process is by its nature carried out outside the plant — such as the application of a Parylene coating — it is handled on the client's side. The shorter and better-controlled the chain, the smaller the risk surface.

Case study: a project from the security industry

The idea of shared responsibility is best illustrated by a real, if anonymised, example. Assel assembles devices for a client from the security industry, where confidentiality and data protection are of particular importance. The division of responsibility here is taken to the extreme — and that is precisely why it works so well.

The client's test devices are located in a separate, dedicated network to which the EMS partner has no access. Logging in to the client's computers is possible only for persons it has approved. All changes and firmware are controlled directly by the client. Data media specified by the client are destroyed solely by authorised external units. As part of this client's operations, Assel is part of its high-level security audit and certification process (EAL4+). This example shows that a mature shared responsibility model is not about the EMS partner "having access to everything", but about every element being assigned to the right party — with boundaries enforced technically, not merely written into a contract.

The organisational and legal layer: contracts, NDAs and audits

Even the best technical safeguards remain fragile without a solid organisational and legal foundation. It is in contracts and procedures that the shared responsibility model acquires binding force.

The foundation is a non-disclosure agreement (NDA), although on its own it is not enough. Mature OEM-EMS relationships rest on detailed clauses in the main contract that specify: the classification and scope of the information entrusted, the required security measures, the rules for engaging subcontractors, audit rights, incident-reporting obligations with deadlines, the rules for retaining and destroying data at the end of cooperation, and the division of responsibility in the event of a breach. In the GDPR context, a separate processing agreement is added.

Audit rights are an instrument that turns declarations into verifiable commitments. The OEM should be able — on its own or through an independent body — to check whether the EMS partner actually applies the agreed measures. Increasingly, this role is also played by certificates from independent bodies (e.g. ISO/IEC 27001), which reduce the need for a separate audit each time.

Subcontractor management closes the loop of responsibility. An EMS partner that itself uses sub-suppliers must ensure that it passes adequate security requirements on to them — otherwise the supply chain remains only as strong as its weakest link, often invisible to the OEM. The NIS2 Directive makes this obligation particularly explicit.

Due diligence: how to verify an EMS partner

Before an OEM entrusts data, it should carry out a thorough assessment of the partner. The checklist below organises the most important areas for verifying a contract electronics manufacturing provider from a data security perspective.

It is worth checking: whether the partner holds an ISO/IEC 27001 certificate or an equivalent information security management system (or is at an advanced stage of implementing one); which quality and industry standards it has implemented (ISO 9001, ISO 13485, ISO 14001); how it delivers business continuity (e.g. based on ISO 22301); how its IT/OT network segmentation and production-environment isolation look; what physical and logical access control mechanisms it uses; how it manages firmware integrity and component traceability; how it controls production volume and prevents overproduction; what data retention and destruction policy it has; how it manages subcontractors; what its incident response procedure looks like; and whether it is willing to accept audit rights and adequate contractual clauses. The answers to these questions quickly separate partners who treat security as part of their strategy from those for whom it remains a formality.

A valuable signal is also the maturity of the new product introduction (NPI) process. A partner who can reliably read and verify the security requirements defined by the client — regarding data classification, the division of responsibility and incident response — and then consistently adapt to them demonstrates that the shared responsibility model is systemic rather than declarative. The starting point is always the client's requirements, not guesses about its intentions.

Implementing the shared responsibility model step by step

The sequence below is a recommended model — in practice its level of detail depends on the requirements defined by the client, and the starting point is always establishing and agreeing those requirements before cooperation begins. Turning theory into practice can be captured in a sequence of actions worth carrying out jointly at the start of every significant project.

The first step is a joint inventory and classification of information assets — establishing what data will be processed and what level of confidentiality it has. The second step is mapping the data flow across the entire project lifecycle, from handing over documentation, through production, to service and withdrawal. The third step is drawing up a responsibility matrix (RACI) and assigning each area to the OEM, the EMS or as a shared area. The fourth step is recording the arrangements in the contract — with audit rights, an incident procedure and retention rules. The fifth step is implementing and verifying technical measures on the EMS side and data-transfer mechanisms on the OEM side. The sixth step is testing and exercises — from an incident simulation to a compliance audit. The seventh step is a periodic review of the model, because both technology and regulation (and NIS2 is the best example) are constantly evolving.

Security across the entire product lifecycle

Responsibility for data does not end the moment the product leaves the line. The shared responsibility model covers the full project lifecycle.

Even before the new product introduction (NPI) stage — when the cooperation is being set up — data classification, the division of responsibility and the documentation exchange channels should be agreed and verified as part of the client's requirements. During series production, carried out within the framework of the requirements agreed before it begins, ongoing access control, firmware integrity, volume control and traceability are key. At the service and maintenance stage, the security of return and diagnostic data must be ensured. Finally, at the end-of-life (EOL) and project-closure stage, the secure, documented destruction or return of data and documentation becomes decisive — so that intellectual property does not "leak" after cooperation ends. Each of these stages has a different main owner, but all share the same principle: no unowned areas.

Conclusion

Data security in contract manufacturing has ceased to be a purely technical issue and has become an element of strategy and regulatory compliance. The shared responsibility model in the OEM-EMS relationship organises this complexity around one fundamental principle: every layer of protection has a clearly assigned owner, and the shared areas are described most carefully. Hard data — USD 5.56 million average cost of a breach in industry, up to USD 125,000 per hour of downtime, or fines of up to EUR 10 million under the NIS2 regime — show that what is at stake is not only reputation but the survival of the business.

For an OEM the practical conclusion is this: choosing an EMS partner means choosing the level of risk for the whole organisation, so maturity in data security — confirmed by certificates, operational mechanisms and a willingness to share responsibility — should weigh as heavily as price and quality. For an EMS partner the conclusion is complementary: the ability to carry shared responsibility and to document it with auditable processes is today one of the strongest competitive advantages. At Assel we treat it as an integral part of the contract manufacturing service — from the secure transfer of a specification, through volume and firmware control, to a clear division of roles all the way to the end of the project's life.

Frequently asked questions (FAQ)

Sources and notes

1. IBM, "Cost of a Data Breach 2024" — industrial sector: average breach cost USD 5.56 million (up 18% YoY), 199 days to identify and 73 days to contain. Source: ibm.com. ↩
2. IBM, "Cost of a Data Breach 2024" — estimated cost of unplanned downtime for industrial facilities: up to USD 125,000 per hour. Source: ibm.com/think/insights. ↩
3. ENISA (EU Agency for Cybersecurity), "Threat Landscape" reports — the supply chain as one of the key attack vectors. Source: enisa.europa.eu. ↩
4. Academic literature on hardware Trojans and counterfeit components, incl. IEEE and ScienceDirect (e.g. "malicious implants in PCBs throughout the supply chain"). ↩
5. IBM, "Cost of a Data Breach 2024" — breakdown of breach root causes in the industrial sector: 47% malicious attacks, 27% human error, 26% system failures. ↩
6. NIS2 Directive (EU) 2022/2555 and the amendment to Poland's National Cybersecurity System Act (KSC); fines up to EUR 10 million or 2% of turnover (essential entities) and EUR 7 million or 1.4% (important entities). ↩