SaMD Engineering Toolchain: How Small Teams Ship FDA-Cleared Software

ContourCompanion received FDA 510(k) clearance as an IMDRF Category IV AI SaMD. The client team at Quantaras was small. No dedicated regulatory department, no in-house compliance staff, no enterprise QMS suite. The clearance happened because the engineering toolchain did the work that headcount does at a large medical device company.

This post maps that toolchain. Every tool and practice listed here earned its place by solving a specific regulatory or operational problem during the project. The series has covered each piece individually: cloud architecture, Infrastructure as Code, CI/CD traceability, cybersecurity, AI/ML validation, and change control. Here is how they fit together as a system.

The Regulatory Surface Area

A Class II SaMD submission touches a stack of standards and regulations that determine your toolchain requirements:

Requirement	Standard/Regulation	What It Demands
Software lifecycle	IEC 62304	Documented SDLC, architecture, unit/integration testing, traceability
Risk management	ISO 14971	Hazard analysis, FMEA, risk controls with verification evidence
Design controls	21 CFR 820.30	Design input/output, verification, validation, design transfer
Quality system	21 CFR 820	Document control, CAPA, complaint handling, management review
Cybersecurity	FDA 2023 guidance	Threat model, SBOM, vulnerability management, SPDF
Data protection	HIPAA	PHI encryption, access controls, audit trails, BAA
AI/ML validation	FDA AI guidance	GMLP, algorithm validation, bias assessment, change control

A large medical device company throws bodies at this list. A department for regulatory affairs, another for quality, another for IT compliance. A startup building its first SaMD does not have that option. The toolchain has to encode regulatory requirements into automated, auditable processes so that a small engineering team can satisfy them without drowning in documentation.

Infrastructure as Code: The Foundation

Every other tool in the stack depends on infrastructure being defined as code. For ContourCompanion, that meant AWS CDK with C#, defining the full production environment (VPC, ECS tasks, RDS clusters, load balancers, encryption configuration, IAM policies) as version-controlled source code.

Three things IaC solved that manual infrastructure cannot:

Reproducibility for IQ/OQ/PQ. GAMP 5 Second Edition classifies IaC templates as Category 1 (infrastructure software), which carries the lowest validation burden. A cdk deploy that produces the same environment every time satisfies Installation Qualification without the multi-day manual verification process. The CDK template is the IQ protocol and the deployment log is the IQ report.

Compliance-as-code with cdk-nag. The cdk-nag library runs compliance rule packs against CDK constructs at synthesis time, before anything touches AWS. The HIPAA Security NagPack flags violations like unencrypted S3 buckets, missing CloudTrail logging, or public subnet placement of database resources. One cdk-nag rule caught a missing encryption-at-rest configuration on an RDS instance that would have been an FDA 483 observation during an inspection. Catching it at build time cost a two-line fix. Catching it in production would have cost a CAPA and a conversation with an FDA investigator.

Drift detection. AWS Config continuously monitors deployed resources against the intended state defined in CDK. Any manual change, an engineer adding a security group rule through the console, for example, triggers an alert. In a regulated environment where the production configuration is part of the design history file, drift is a compliance violation. Automated detection prevents it from persisting.

Automated Traceability: From Requirement to Deployment

FDA's design controls require a requirements traceability matrix that links every requirement to its design output, verification activity, and validation evidence. For a spreadsheet-based RTM, updating this before each submission takes days of manual cross-referencing. For ContourCompanion, the RTM was generated from the development toolchain itself.

The traceability chain:

1. Requirements lived in Jira tickets with structured fields (requirement ID, risk reference, acceptance criteria)
2. Design outputs were code changes linked to Jira tickets via commit messages and branch naming conventions
3. Verification was automated test results mapped to requirement IDs through test naming conventions
4. Validation was clinical evaluation data linked to the requirements it addressed

The CI/CD pipeline enforced the chain. A pull request that did not reference a Jira ticket could not merge. A Jira ticket without acceptance criteria could not be marked complete. Test results were archived with build artifacts, creating an immutable record that FDA reviewers could follow from any requirement to its verification evidence.

The RTM that used to take days to compile was generated in minutes. More importantly, it was always current. A spreadsheet RTM is a snapshot that starts going stale the moment someone merges a PR. An automated RTM is a live document that reflects the actual state of the codebase.

Container Deployment: Immutability as a Regulatory Strategy

ContourCompanion runs as containerized services on AWS ECS. The containers handle DICOM data ingestion, AI inference, and result delivery. The choice of containers was not a preference. It was a regulatory decision.

The container image is the validated artifact. When the FDA clears a SaMD, they clear a specific version of the software. For ContourCompanion, that version is a container image with a pinned tag stored in Amazon ECR. Same image, same weights, same dependencies, same output. The image digest (SHA256 hash) is the version identifier that ties the cleared software to its validation evidence. As discussed in the AI/ML post, this is what "locked algorithm" means in practice.

SBOM generation is automated. The FDA's 2023 cybersecurity guidance requires a Software Bill of Materials for premarket submissions. Tools like Syft and Trivy generate SBOMs directly from container images, producing CycloneDX or SPDX-format output that lists every OS package, language library, and transitive dependency. The SBOM is generated as part of the CI/CD pipeline, archived alongside the container image, and included in the submission package. No manual dependency inventory.

Vulnerability scanning runs continuously. Amazon Inspector scans ECR images for known CVEs in both OS packages and application dependencies. When a new CVE is published that affects a dependency in a deployed container, an alert fires. The cybersecurity post-market plan requires ongoing vulnerability monitoring. Automated scanning against the SBOM satisfies that requirement with zero manual effort.

ClamAV scans container images for malware before they enter the deployment pipeline. This is belt-and-suspenders, but FDA reviewers notice it in the cybersecurity submission, and it demonstrates the Secure Product Development Framework (SPDF) controls they are looking for.

The CI/CD Pipeline as a Quality System

The CI/CD pipeline is not just a deployment mechanism. It is the enforcement layer for the quality system. Every merge to the main branch triggers a sequence that encodes 21 CFR 820 requirements:

Pipeline Stage	Regulatory Purpose	What Fails the Build
Static analysis	Code quality, vulnerability detection	Critical findings from SonarQube/Semgrep
Unit/integration tests	Design verification (820.30(f))	Any test failure
SBOM generation	Cybersecurity documentation	Generation errors
Container build + scan	Validated artifact creation, vulnerability check	Critical/high CVEs
cdk-nag synthesis	Infrastructure compliance	HIPAA NagPack violations
Approval gate	QA sign-off before production	Missing approval
Deployment + IQ script	Design transfer (820.30(h))	IQ verification failures

If any stage fails, the pipeline stops. No manual override, no "ship it and fix it later." The pipeline is the design control process expressed as code. An FDA auditor reviewing the design history file sees the same pipeline that ran for every production deployment: which tests passed, which scans ran, who approved, what was deployed.

Break-Glass Access: When the Pipeline Is Not Enough

Production access is locked down by default. Engineers cannot SSH into ECS tasks. Database access requires IAM role assumption through a documented break-glass procedure with 60-minute session limits. Every break-glass event triggers an immutable CloudTrail log entry and an instant alarm to the operations channel.

This is not paranoia. It is a HIPAA requirement and an FDA expectation. The cybersecurity submission must demonstrate access controls for the production environment. "We use IAM roles with time-limited sessions and immutable audit logs" is a concrete answer to a question FDA reviewers will ask.

What the Toolchain Replaces

The point is not the tools themselves. It is what they replace:

Traditional Approach	Toolchain Approach	Impact
Manual IQ/OQ/PQ protocols	CDK deploy + IQ script	Days → minutes per environment
Spreadsheet RTM	Automated from Jira + Git + tests	Always current, generated in minutes
Manual SBOM inventory	Syft/Trivy on container images	Automatic with every build
Periodic vulnerability scans	Continuous ECR/Inspector scanning	Real-time alerting
Manual compliance audits	cdk-nag + AWS Config	Shift-left, catch before deploy
Document-based change control	Git history + pipeline approvals	Immutable, auditable, searchable

Each row is a regulatory activity that, done manually, requires dedicated staff. Done through the toolchain, it is a pipeline step. That is the force multiplication: regulatory compliance encoded into the development process rather than bolted on as a separate activity.

The Democratization Thesis

Five years ago, building an FDA-cleared AI SaMD required a large organization with established regulatory infrastructure, clinical relationships, and deep pockets. The cost structure was prohibitive for startups.

That has changed. Cloud QMS platforms provide quality system structure at startup-friendly pricing. IaC eliminates the gap between development and production environments. Container-based deployment gives you immutable, validated artifacts. Automated traceability generates the documentation that used to require a full-time regulatory affairs team. The FDA's own modernization (Computer Software Assurance guidance, eSTAR, PCCP) signals that the agency expects and supports automation-first approaches.

ContourCompanion is the proof. A startup with domain expertise and clinical relationships (Quantaras), paired with an engineering partner that knew how to build regulated software on AWS (Quantiva), shipped an FDA-cleared AI medical device. The toolchain made it possible. Not easy. Possible.

The series plan at the start of this project had one question: can a small, focused team build and clear an AI SaMD without a 200-person regulatory department? The answer is yes, if the engineering is right.

References

• GAMP 5 Second Edition (ISPE, 2022)
• cdk-nag: CDK Compliance Checking
• AWS Config: Continuous Compliance Monitoring
• Amazon Inspector: Container Vulnerability Scanning
• FDA Computer Software Assurance Guidance (September 2025)
• FDA 21 CFR Part 820: Quality System Regulation
• IEC 62304: Medical Device Software Lifecycle
• Syft: SBOM Generation
• Trivy: Container Security Scanner
• FDA eSTAR Program