SSD Supplier Audit Checklist: NAND, Controller, Firmware, QC and Traceability

Two drives, same model number, same silkscreen, same box. One shipped in March, the other in September. Pop the labels off and the September unit is running a different NAND generation and a controller revision nobody told you about. Both of them clear the thirty-second benchmark your supplier's sales engineer ran on a laptop in the meeting room. Only one of them is the drive your team actually qualified.

That gap is the reason an SSD supplier audit exists. Price lists, a certificate PDF and three hand-picked engineering samples tell you what a factory can build once, under attention, when it wants your business. An audit is supposed to tell you something harder: whether the same approved configuration comes off the line in unit 40,000 as it did in unit 12, and whether anyone at the factory could prove it to you if a field failure showed up eight months from now.

Which is why a storage audit isn't a general factory walkthrough with the word NAND sprinkled in. The quality system still matters, obviously. But you also have to verify component identity down to a part number, firmware down to a build, sustained performance past the point where the cache runs dry, and traceability that survives working in both directions. Most published supplier checklists stop at document control and PPE. This one doesn't.

Bottom line up front An SSD supplier audit has one job: prove that mass production matches the configuration you approved. Everything else is supporting evidence. Verify the controller part number and NAND generation against a controlled BOM, verify the firmware build against a release record and a read-back from a finished drive, then run a live mock trace from one serial number back to component lots. If a factory can pass those three and show you a corrective action that actually closed, the rest of the audit is usually detail. If it can't, a spotless floor and a wall of certificates don't cover the gap.

SSD Supplier Audit Checklist: The Short Answer

A supplier audit checklist is a structured, scoreable form that walks an auditor through a vendor's quality system, sourcing controls, production process and compliance evidence in the same order every time, so two suppliers can be compared on the same criteria instead of on impressions.

What the audit has to prove

Repeatability, in one word. Every section you score is really asking a version of the same question, which is whether this factory can build the drive you approved again without quietly swapping something, and whether component identity, firmware control, test limits tied to a spec, failure handling and lot records would still hold up under a customer complaint six months from now.

Where these audits usually break down

Rarely in the sections you'd expect. Housekeeping is fine, the ISO certificate is current, work instructions are laminated at every station. Then you ask which NAND lot went into a specific finished batch and the room goes quiet, or somebody opens a spreadsheet with no lot column in it. That's the finding. Not the dust.

The one-line version

Audit the identity of the parts, the control of the firmware, and the traceability that links them to a serial number. Score those heaviest. Everything else supports the decision without deciding it.

What an SSD Supplier Audit Actually Verifies

An audit should connect five things into one evidence chain: the quality system, the sourcing records, the firmware, the manufacturing and test controls, and finished-drive traceability. Break any link and the rest stop meaning much, because a perfect test report is worth very little if you can't tell which BOM the tested drive was built to, and a locked BOM proves nothing if nobody can show that the line actually followed it. Five things, one chain.

Audit the floor, not the binder

Procedures are a starting point. Nothing more. Walk receiving, storage, SMT, programming, test, quarantine, final inspection and shipping in that order, compare what's written against what people actually do at the bench, and keep in mind that a process living only in a quality manual shouldn't score the same as one an operator can demonstrate using today's records.

Turn every claim into an evidence request

This is the single habit that separates a useful audit from a tour. Supplier says the BOM is locked? Ask for the controlled BOM plus the change log for the last twelve months. Says every drive gets functional test? Pull the log for the lot that ran this morning. Says failures get root-caused? Pick three from last quarter, different failure modes, and read them end to end.

Grade findings before you get on the plane

Classify severity in advance, along with the automatic-fail list and the minimum score, because deciding what counts as acceptable after you've seen the pricing is how serious findings get talked down into observations. Write it down beforehand. Then it's a comparison instead of an argument.

Audit Domain	What You Verify	Evidence to Pull On Site
Quality system	Document control, internal audits, CAPA, management review, quality authority	Certificate scope, audit schedule, three closed corrective actions
Sourcing and BOM	Controller part number, NAND vendor and generation, DRAM, PCB revision, approved alternates	Controlled BOM, purchase records, approved supplier list
Incoming QC	Identity verification, lot acceptance criteria, quarantine of rejects	Recent NAND and controller receipts with disposition
Firmware	Release approval, version control, archived builds, programming station control	Release record, programming logs, read-back from finished units
Production and test	Work instructions, machine settings, in-process gates, functional and sustained tests	One completed lot record end to end, test limits file
Reliability	Burn-in, endurance basis, thermal behaviour, data integrity after stress	Burn-in yield data by lot, endurance report naming the tested BOM
Traceability	Serial to lot, lot to component, firmware to serial	Live mock trace, timed, using records the team uses daily

The Pre-Audit Checklist: What to Ask For Before You Fly

A pre-audit checklist is the document request you send ahead of the visit, so your two days on site go into verification instead of photocopying, and so you land already knowing which two or three areas deserve most of your attention. Read what comes back properly. The gaps in it are telling you where to spend your time.

Lock the scope, including the second site

State whether this covers a new supplier, a new platform on an approved supplier, or a follow-up on old findings. Name the capacities, interfaces and factory address. If firmware programming or PCB assembly happens somewhere else, and it often does, that address goes into the scope too, otherwise you'll spend two days auditing the site that doesn't perform the operation you came to verify.

The controlled BOM, not a marketing spec

"TLC NAND with a PCIe Gen 4 controller" is a product description, not a bill of materials. What you need is the controlled document with the controller manufacturer and part number, the NAND vendor and generation, DRAM where it's used, the PCB revision, the firmware build, and any approved alternates with the conditions attached to them.

Records from a real lot

Ask for a package from recent production rather than a pilot run assembled for your benefit, meaning incoming inspection records, programming logs, functional and performance results, burn-in data, failure reports, final inspection and the shipment release for one real lot. If the only complete set anyone can find comes from a pilot build, write that down. It's a finding about record-keeping rather than about the pilot.

Last year's findings

Request the previous internal, customer and certification audit findings that touch the processes you're auditing, then check whether the corrective actions closed and whether the same issue reappeared later under a different case number. Repeat findings mean somebody is closing paperwork. Not fixing a process.

Send the document request three weeks out Two weeks is enough time for a factory to produce documents and not enough for you to read them properly before travel. Three weeks gives you a week to build a targeted question list, which is where the audit's value actually comes from.

Quality System Checks That Are Worth Your Time

An ISO audit checklist maps your questions to clauses of a management standard so the evidence you collect lines up with what a registrar or a customer would expect to see. For supplier work the relevant part is narrow: ISO 9001:2015 puts specific requirements on the control of externally provided processes, products and services, which is exactly the situation an SSD factory is in when it depends on upstream NAND, controller, DRAM and PCB vendors.

Read the certificate scope, not the logo

Check the certificate number, the certification body, the expiry date and, above all, the scope and the address, because a certificate covering a sister plant or the assembly of an entirely different product family tells you nothing at all about the line building your drives. Ninety seconds of reading. It catches more than people expect.

Document control on the floor

Pick a station at random and ask the operator which revision of the work instruction is current. If they have to guess, or if a superseded copy is still taped up beside the live one, document control isn't working no matter what the procedure says, and the same quick test applies to BOMs, test limit files and firmware release notes.

Follow one corrective action all the way to the end

Choose a real problem from last year and trace it through containment, root cause, permanent fix, owner, completion date and effectiveness check. Replacing the defective units is containment. If that's where the record stops, you've found a corrective action process that can't reduce recurrence, and that single finding tends to predict most of what goes wrong later in the relationship.

Who can override a rejection

Quality staff need real authority to stop, quarantine and reject. So ask the uncomfortable question: who can overrule them, and does that person have to sign something? Informal production pressure is the mechanism by which good systems fail quietly. On the partner side of this table, how Digiera documents its sourcing and build chain is public for the same reason, since a buyer shouldn't have to take a supplier's word for where product control sits.

NAND and Controller Sourcing: The Identity Question

Here's the part generic checklists skip. NAND and the controller together determine capacity behaviour, endurance, sustained write speed, thermals and compatibility, and a substitution in either one can produce a genuinely different drive wearing the same model number. NIST's supply chain risk management guidance frames the underlying exposure well: buyers lose visibility into how the technology they purchase is built, and that's where counterfeit or poorly controlled components get in.

Name the part, not the family

Record the exact controller manufacturer, part number and silicon revision. Family-level descriptions are not identity. A different controller inside the same family can change firmware compatibility, power behaviour, NAND support and sustained throughput, and you will not see any of that on a thirty-second sequential benchmark.

Lot records have to work in both directions

Pick a recent NAND lot and follow it forward into finished batches, then pick a finished batch and follow it back to the NAND that went into it, using the records the team touches every day rather than a reconstruction assembled during your visit. Both directions. If only one of them works, containment during a field problem gets expensive fast.

TLC, QLC and the capacity trap

Don't assume one product family uses one flash configuration across every capacity. It often doesn't. Confirm TLC or QLC per capacity, and confirm whether DRAM-less architecture applies to some SKUs and not others, because that detail changes random performance and it belongs in the approved configuration in writing.

Storage, moisture and the popcorn problem

Walk the component store. Flash and controllers are moisture sensitive devices, and IPC/JEDEC J-STD-033 sets out the handling, dry packing and floor-life rules that keep absorbed moisture from vaporising during reflow and cracking a package open. Check opened-bag controls, humidity indicator cards, bake records, and whether the floor-life clock is actually being tracked per bag. When a factory can build to both internal NVMe and SATA configurations on the same line, that store is holding several component families at once, and lot segregation gets harder rather than easier.

Firmware Control and the Programming Station

Firmware decides how the drive handles power states, caching, error recovery, NAND management and health reporting, which is why two units with identical hardware and different builds can behave differently enough to break a compatibility matrix you already signed off. So firmware gets the same control you apply to physical parts. Verifiable on a finished drive, not on a release note.

Who builds it and who can change it

Ask whether firmware comes from the controller vendor, the SSD manufacturer, an ODM or a third engineering partner, then ask who holds authority to modify it and who handles escalation when something breaks in the field. Vague answers are their own finding.

The release gate

Firmware shouldn't reach a programming station because an engineer dropped a file into a shared folder. Look for a formal release: what changed, why, who approved it, what testing was done, which products and lots received it, and a checksum or image identity control that stops an unfinished build from being loaded by accident.

Read back from finished drives

Sample finished units off the line and read the active firmware revision, then compare it against the release record and the golden sample. This is practical rather than theoretical, because NVMe defines standard management and health reporting including the SMART log page, percentage used, a device self-test command that many factories already run at build, and a persistent event log that timestamps firmware updates and formats like a black box recorder.

What happens when programming fails

Follow a failed unit physically. It should move into a controlled failure or rework flow, get labelled, and get retested against the function the rework touched, because a drive that quietly rejoins normal production after a second programming attempt is a traceability break and a field risk at once.

Ask them to retrieve an old build Request a production firmware version from two releases back, on the spot. If nobody can recover it, you've lost your only tool for reproducing a field issue that appeared before the newest update shipped. It's a five-minute test that tells you whether version control is real.

Locked BOM, PCN and Change Control

Every hour your engineering team spent qualifying a drive is protected by one thing: a locked BOM plus a change process with your signature in it. Without that, the supplier can change the product and keep the commercial model number, and your qualification report quietly stops describing what's in the box.

What gets locked

For storage, the locked list normally runs to NAND, controller, firmware, DRAM where present, PCB revision and the major power and interface components, and it belongs inside the agreement rather than inside somebody's interpretation of the agreement. Ambiguity resolves in favour of whichever part is cheaper this quarter. Every time.

Who signs off

Procurement shouldn't be able to substitute a critical component because a second source came in cheaper. Ask who requests, who reviews and who authorises, then confirm in writing that buyer-controlled parts need buyer approval before the new configuration enters mass production, because approving a product name is not the same as approving every future combination inside it.

Notification lead time that means something

A product change notification is only useful if it arrives while you can still act. You need enough runway to receive samples built with the new configuration and test them properly, which means the notice has to land before the new material enters production. Before, not after. Match requalification scope to the change, so a firmware revision draws compatibility, power and telemetry work while a NAND swap draws endurance, sustained write and data integrity testing.

Record the lot boundary

Ask for the last lot built on the old BOM and the first lot built on the new one. That boundary is what makes a future field investigation narrow instead of total, and factories that already track it are telling you something good about their change discipline.

Production Testing Beyond the Peak Benchmark

Short benchmarks flatter every SSD. They run inside the fast cache, at room temperature, on an empty drive, which is the one condition your application will almost never be in, and sustained behaviour is where drives separate and where a qualification either earns its keep or doesn't. If you're evaluating something like a PCIe Gen 4 NVMe drive for a build that writes continuously, the number that matters is the one after the cache is gone.

Write past the SLC cache

Push enough data to exhaust the fast-cache window, then record where throughput drops, what speed the drive holds afterwards, and any latency stalls along the way, because an averaged figure hides exactly the stall that will hurt an OEM workload. Minimum sustained, not mean.

Test the drive partly full

Repeat at realistic fill levels, somewhere around seventy or eighty percent for most client use. An empty drive has more room for cache and background management than a drive holding real customer data, and the difference is often larger than the difference between two competing models.

Let it reach thermal state, then measure again

Fast drives get hot because they're moving data fast, and Gen 4 and Gen 5 units throttle when they cook, so log temperature through a long workload and record ambient conditions, cooling, orientation and whether a heatsink was fitted. The audit question isn't whether the drive throttles. It's whether the throttled number still meets your requirement.

Sample across lots, not across one tray

One excellent unit proves nothing about mass production. Test multiple drives from different lots and different shifts, then compare them, because drift between lots points at component variation, assembly variation or a firmware change nobody flagged, and catching that during qualification is far cheaper than catching it in the field.

Test Gate	What to Measure	Red Flag
Functional / identity	Mounts, reports correct capacity, model, serial and firmware	Label correct, reported identity different
Sequential throughput	Read and write under defined conditions, per capacity	One limit file applied to every capacity
Sustained write	Speed and stall behaviour after cache exhaustion	Only pre-cache figures on record
Random I/O	Workload settings resembling the application, not peak IOPS	Queue depth chosen to produce the best number
Thermal	Temperature through long workload, throttled sustained speed	Bench test only, no ambient recorded
Burn-in	Duration, workload, power cycles, failure rate by lot	Powered on but idle for the whole window
Data integrity	Verified checksums after stress and power events	Written but never read back

Endurance, Telemetry and Reliability Evidence

Endurance validation has to cover the exact controller, NAND, firmware and capacity you're buying, because a report generated on a different NAND generation is a document rather than proof, however professional the cover page looks. Ask what the rating rests on. The answer should contain a workload, a sample size, a write volume, health data and an end-of-test criterion.

Where the TBW number comes from

TBW isn't a marketing figure by default, and it shouldn't be treated as one. JEDEC's JESD218 defines an SSD endurance rating in terabytes written by the host, splits requirements into client and enterprise application classes, and sets out two verification routes, direct stress to the full rating or extrapolation where that isn't achievable in reasonable time. Ask which route the supplier used. The answer tells you how much of the number was measured.

Burn-in that actually stresses something

A drive sitting powered on for six hours has not been tested. Look for meaningful reads and writes, power cycles and elevated temperature where the product spec justifies it, ask how the duration was chosen, and treat a longer window as evidence only when somebody can map it to a known failure mode.

Health reporting you can trust

List the health fields the shipping firmware exposes, then check that support engineering understands what each one actually means. Validate two of them on the spot, comparing device-reported temperature against an external reference during a controlled test and confirming that host-write counters climb as expected under a documented unit conversion. Fleet monitoring built on an unvalidated field is worse than none.

Data integrity after stress

Written test data needs to be read back and verified, with checksums or another controlled comparison, after endurance runs and after unexpected power removal, and growing bad-block counts or error spikes across the window deserve a look as well. A drive that finishes an endurance run with clean data and a smooth wear curve is telling you the NAND and controller pairing works.

ESD, Handling and Line Discipline

Electrostatic damage doesn't announce itself. A wounded controller can pass functional test and fail at a customer site four months later, which makes ESD control one of the few audit areas where the process evidence matters more than any test result you can collect on the day.

Inside the ESD protected area

Inspect wherever sensitive devices get unpacked, assembled, tested or reworked. ANSI/ESD S20.20 frames a control program around personnel grounding, equipotential bonding, packaging, flooring, marking, training and compliance verification, with the companion TR53 report covering verification of the control items themselves. Look for the verification schedule and the recent readings, then watch operators work. Behaviour beats folders.

Housekeeping and 5S, in proportion

A 5S audit checklist scores sort, set in order, shine, standardise and sustain, and it's genuinely useful for spotting a line that's drifting. Just weight it honestly. Dust, food at a workstation and uncontrolled personal items near open trays are real risks; a slightly untidy office is not the same category of problem as NAND lots sharing a bin.

Traceability and the Mock Trace

Traceability is the difference between containing a problem and recalling everything you've ever received. It's also the easiest thing to test in an audit, because you can just ask for it live and time how long the answer takes.

Backward from a serial number

Hand them a random finished drive. From that serial number they should reach production lot, firmware revision, controller lot, NAND lot, inspection records, test results and shipping record, and you want to watch how the team gets there rather than only whether they arrive. Three systems plus a phone call to another department is a different answer from one query.

Forward from a NAND lot

Then reverse it: choose an incoming lot and ask which finished production lots consumed it. This is the direction that matters when a component supplier issues a notice, and it's the direction that fails more often, since forward linkage tends to be reconstructed rather than recorded.

Firmware to serial number

Pick several serials and ask which firmware build shipped on each. When a field issue turns out to be firmware specific, and plenty do, this record decides whether you're containing four thousand drives or four hundred thousand.

If the mock trace fails, stop scoring and start negotiating A factory that can't complete a trace with normal records isn't going to build that capability during a field crisis. Either it becomes a critical finding with a hard corrective action and a follow-up visit, or the sourcing decision changes. Don't let a strong test report offset it, because the test report is one of the things you'd lose the ability to connect to shipped product.

Non-Conforming Product and Failure Analysis

Failed drives are the most honest part of any factory. How they get labelled, held, reworked, retested and scrapped tells you what the quality system does under pressure rather than on paper.

Quarantine you can actually see

Visit the physical hold area. Status should be obvious from two metres away, access should be controlled, the inventory system should agree with what is physically on the shelf, and accepted, pending, quarantined and rejected material sitting in adjacent unlabelled bins is a mixing risk waiting for a busy shift.

Rework with instructions, retest with purpose

Rework needs approved instructions rather than bench improvisation, the retest afterwards has to cover both the repaired function and any new risk the repair introduced, and scrap quantities should reconcile against failure records, since gaps there sometimes mean units left the failure flow without ever being scrapped. Check the numbers.

Root cause versus symptom

"Drive failed test" is a symptom. A root cause names a component, a process parameter, a firmware behaviour, a handling condition or a test escape, and it comes with evidence. Ask how RMA and customer data gets back to manufacturing, because field information should be updating test limits and work instructions, not sitting in a support queue.

Scoring, Red Flags and Corrective Actions

A scoring system turns two days of notes into a sourcing decision somebody else can review, so weight the sections that carry product risk, keep observations separate from real failures to protect the meaning of the final number, and set the approval threshold before you know the price. Order matters here.

Severity	Definition	SSD Example
Critical	Threatens product identity, legal compliance or traceability. Blocks production.	Unknown or undisclosed controller, uncontrolled firmware, failed mock trace, known-failed units shipped
Major	Serious failure of an important control, system-level weakness.	BOM changes without buyer approval, ineffective corrective actions, no incoming control on critical parts
Minor	Narrower gap, correctable within an agreed period.	Superseded work instruction at one station, incomplete calibration label, thin inspection notes
Observation	Improvement opportunity, not a non-conformance.	Store layout slows lot picking, test report formatting inconsistent between lines

Red flags that outrank a clean factory

Some findings should move your risk rating regardless of how the audit scores overall:

• The controller model isn't disclosed in an OEM program.
• NAND can be substituted without notice, which invalidates every endurance and sustained-write result you have.
• Nobody can say which firmware shipped in a given lot.
• There's no locked-BOM commitment, only a model number.
• Production testing consists of peak benchmarks and nothing else.
• Repeated refusal to show BOM control, test records or corrective actions. Commercial sensitivity is fair; a total evidence blackout isn't.

Close the majors before the purchase order

Assign a named owner to every material finding, set deadlines that match risk, and require objective evidence for closure. Revised procedures, training records, production logs, photos, test results. An email saying it's fixed is not closure, and unresolved major findings have a habit of turning into informal promises the moment a PO lands.

Then verify that the fix held

Ask for post-action evidence from a later lot, and use a focused follow-up visit where a physical process changed. If the seven-step framing helps your team, the sequence is roughly: define scope and criteria, prepare and desktop-review, conduct the audit, classify findings, report, assign and close corrective actions, then verify effectiveness. Same logic, different label.

Final Verdict: When to Approve an SSD Supplier

Approve when the factory can show repeatable evidence for component identity, firmware control, sustained performance, failure handling and lot traceability, and keep in mind that price, capacity and lead time all matter without ever offsetting a supply chain that changes faster than you can verify it. Suppliers that publish OEM and reseller partner terms up front tend to make this stage shorter, simply because procurement can start due diligence before the first call.

Your situation	Where to put the weight
First order with a new factory	Component identity and locked BOM first. Get the mock trace done on day one, before the tour.
Requalifying an approved supplier	Change history and PCN records. Compare a current lot against the golden sample.
Chasing a field failure	Firmware-to-serial linkage and failure analysis quality. Everything else can wait.
Scaling volume quickly	Capacity claims against real output records, plus whether controls scale with extra shifts.
Single-source component risk	Approved alternates and requalification triggers, written down rather than implied.

Conclusion

Strip this back and an SSD supplier audit answers one question. Does mass production match the drive you approved? Certificates and benchmark samples don't answer it. A traceable chain running from NAND and controller lots through firmware, assembly, test data and finished serial numbers does, and the factories that can show you that chain are usually the ones you want. For buyers evaluating the storage lineup Digiera curates, the same logic applies in reverse: as a curated reseller and OEM / ODM partner rather than a chip fabricator, the value sits in documented sourcing, controlled configurations and a build record somebody can actually trace.

One practical suggestion to close on. Don't try to run all fourteen sections at full depth on your first visit, because you'll do everything shallowly. Pick the three that carry the most risk for your product, which for most storage programs means component identity, firmware control and traceability, and audit those to the floor. The rest gets you a score. Those three get you a decision.

FAQs

What is a supplier audit checklist?

It's a standardised, scoreable form that walks an auditor through a vendor's quality system, production controls and compliance evidence in the same order every time. The point is comparability, so two suppliers get measured against identical criteria instead of against whichever visit felt better.

What should be included in an audit checklist?

Seven areas cover most programs: quality management system, procurement and incoming material, in-process controls, final inspection, calibration, document control and traceability, plus health and safety. For storage you add component identity, firmware control, sustained performance and capacity-specific test limits, since a PCIe Gen 5 NVMe SSD and an M.2 SATA drive don't share a test plan.

How do you prepare for a supplier audit?

Define scope and criteria, send the document request about three weeks out, then run a desktop review before travel so that on-site time goes into verification and your question list is already built from the gaps in what came back. Walking in with generic questions is how two days disappear.

What is a pre-audit checklist?

The list of documents and records you request before the visit: quality manual, process flow, approved BOM, recent production and test records, previous findings. It should name the exact configuration under review, right down to an M.2 2280 SATA III drive rather than a product family, because a family-level scope produces family-level evidence.

What is an ISO audit checklist?

One that maps questions to clauses of a management standard, usually ISO 9001 for supplier work, so your evidence lines up with what a registrar or customer expects. Read the certificate scope and address carefully. A certificate for a sister plant proves nothing about the line building your product.

What are the 7 steps in the audit process?

Define scope and objectives, develop criteria and build the checklist, run a desktop review, conduct the on-site or remote audit, classify and score findings, report and assign corrective actions with owners and deadlines, then verify effectiveness later. Different frameworks label these differently, though the sequence rarely changes.

What are the 5 C's of auditing?

Criteria, condition, cause, consequence and corrective action. They're the parts of a well-written finding, covering what the requirement was, what you observed, why it happened, what the risk is and what the supplier will do about it, which is why findings missing cause or consequence tend not to get fixed properly.

What is a 5S audit checklist?

Sort, set in order, shine, standardise and sustain, scored across a work area. It's a useful signal for a line that's drifting and worth keeping in the checklist, though a tidy floor shouldn't carry the same weight as NAND lot traceability, because only one of those two ships defects to your customers.

Sources

1. ISO, ISO 9001:2015 quality management systems requirements
2. JEDEC, JESD218 solid-state drive endurance rating and application classes
3. NVM Express, SMART, log pages, telemetry and error reporting in NVMe architectures
4. IPC / JEDEC, J-STD-033 handling, packing and shipping of moisture sensitive devices
5. EOS/ESD Association, an overview of ANSI/ESD S20.20 control program requirements
6. NIST, SP 800-161 Rev. 1 cybersecurity supply chain risk management practices