Infrastructure as Code for Medical Devices: IQ OQ PQ with AWS CDK

Infrastructure as code for medical devices is a regulatory strategy. When the FDA asks "how do you know your production infrastructure matches your validated design," teams using manual provisioning reach for screenshots and spreadsheets. Teams using IaC point to a Git commit hash. The CDK code is the specification, the deployed infrastructure is its verified output, and the gap between the two is zero.

For ContourCompanion, a Class II AI SaMD processing DICOM CT data on AWS, we defined the entire infrastructure in AWS CDK with cdk-nag HIPAA NagPacks catching compliance violations at synthesis time. One cdk-nag rule caught a missing S3 encryption configuration on a staging bucket that would have been a 483 observation in an FDA inspection. That rule ran on every cdk synth, long before anything touched AWS.

What follows is how IaC maps to GxP qualification, why GAMP 5 now endorses it, and how CDK testing generates the IQ OQ PQ evidence that FDA reviewers expect.

GAMP 5 and the Regulatory Basis for Infrastructure as Code

GAMP 5 Second Edition (July 2022) changed the compliance calculus for cloud infrastructure. The first edition didn't address IaC. The second edition explicitly endorses it as an approved provisioning method, places cloud infrastructure in a new Appendix M11, and introduces "critical thinking" (Appendix M12) as the replacement for prescriptive validation checklists.

Under GAMP 5's classification system, cloud infrastructure provisioned through IaC falls into Category 1 (Infrastructure Software). Category 1 requires qualification, not full validation. Qualification verifies that the infrastructure operates as specified. Validation proves the entire system meets user requirements. The IaC template is the specification. Automated tests verify the deployed state matches it. The qualification burden is a fraction of what full CSV (Computer System Validation) demands.

The FDA's Computer Software Assurance (CSA) guidance (finalized September 2025) reinforces this direction. CSA replaces the older CSV guidance with a risk-based approach that explicitly endorses automation, continuous monitoring, and automated testing as valid assurance activities. If your IaC tests verify that encryption is enabled, access controls are correct, and network isolation is enforced, those tests are CSA-acceptable assurance evidence.

The AWS GxP Systems whitepaper ties it together: IaC templates serve as "pre-approved specifications" that can be compared against deployed stacks, with summary reports and test evidence generated automatically. AWS reports that customers using IaC-based qualification see a 30-40% reduction in qualification times and 60% reduction in IQ cycle times compared to manual approaches.

ISPE's GAMP IT Infrastructure Guide states: "the validated status of GxP applications can be compromised if the IT Infrastructure is not maintained in a demonstrable state of control." IaC is how you maintain that demonstrable state. Manual infrastructure can never prove it hasn't drifted.

How IaC Replaces Manual IQ OQ PQ

IQ OQ PQ (Installation Qualification, Operational Qualification, Performance Qualification) is the traditional framework for proving that infrastructure works as specified. In manual environments, each stage generates a paper trail: screenshots of console settings, signed checklists, test execution records. For ContourCompanion's HIPAA compliant AWS architecture, that would have meant manually verifying encryption on every RDS instance, every S3 bucket, every EBS volume, every KMS key, across multiple accounts, every time the infrastructure changed.

With IaC, each stage maps to a different phase of the CDK pipeline:

Installation Qualification with CDK

IQ verifies that the system is installed according to specification. The AWS GxP whitepaper states: "What hasn't been possible before is the fully automated deployment of infrastructure and execution of the Installation Qualification (IQ) step."

With CDK, the IaC template is the specification. After cdk deploy, the IQ script compares the deployed CloudFormation stack outputs against the expected values in the CDK code. Did the RDS instance get created with the correct engine version, storage encryption, and Multi-AZ configuration? The CloudFormation API answers that question programmatically. The IQ report is a timestamped JSON document, not a signed checklist.

Operational Qualification with CDK Assertions

OQ verifies that the system operates correctly within specified parameters. CDK fine-grained assertions handle this at synthesis time, before deployment:

template.hasResourceProperties('AWS::S3::Bucket', {
  BucketEncryption: {
    ServerSideEncryptionConfiguration: [{
      ServerSideEncryptionByDefault: {
        SSEAlgorithm: 'aws:kms',
        KMSMasterKeyID: { 'Fn::GetAtt': ['PhiEncryptionKey', 'Arn'] }
      }
    }]
  },
  PublicAccessBlockConfiguration: {
    BlockPublicAcls: true,
    BlockPublicPolicy: true,
    IgnorePublicAcls: true,
    RestrictPublicBuckets: true
  }
});

That test proves the DICOM staging bucket uses KMS encryption with a customer-managed key and blocks all public access. It runs in CI without AWS credentials. If someone modifies the bucket construct and removes encryption, the test fails before the pull request merges. The OQ evidence is the test suite output, generated on every build.

Performance Qualification as Post-Deploy Verification

PQ verifies that the system performs as expected under production conditions. This maps to the post-deployment verification scripts we described in our HIPAA architecture post: checking that VPC endpoints are operational, security groups match the approved configuration, cross-region replication is active, and RDS Multi-AZ failover works as specified.

The PQ script runs after every CDK deployment. It calls the AWS APIs directly: describe the RDS cluster (is Multi-AZ active?), list S3 replication rules (is CRR configured?), check CloudTrail status (is integrity validation enabled?). Each check maps to a design requirement in the risk management file. The output is a structured report that feeds into the traceability matrix.

Qualification Stage	Manual Approach	IaC Approach
IQ	Screenshots of console, signed checklists	CloudFormation stack comparison against CDK template
OQ	Manual test execution with documented results	CDK assertions + cdk-nag in CI, no AWS credentials needed
PQ	One-time production verification	Automated post-deploy script, runs on every deployment
Re-qualification	Repeat everything	Runs automatically, same evidence every time

The re-qualification row is where the time savings compound. Manual IQ/OQ/PQ is a project. Every infrastructure change triggers another round. With IaC, re-qualification is a CI pipeline stage that takes minutes.

cdk-nag: Shift-Left Compliance for Medical Devices

cdk-nag is maintained by cdklabs (Amazon's CDK team) and validates CDK constructs against compliance rule sets called NagPacks. The HIPAA Security NagPack maps rules to specific HIPAA Security Rule controls (e.g., 164.312(e)(1) for encryption in transit). Unsuppressed errors prevent cdk deploy from executing. You cannot deploy non-compliant infrastructure.

We applied three NagPacks to every CDK stack:

1. HIPAA Security for PHI protection controls
2. NIST 800-53 rev 5 for the broader security baseline
3. AWS Solutions for general best practices

The NagPacks overlap deliberately. A rule that HIPAA misses, NIST catches.

cdk-nag generates compliance reports as CSV files in cdk.out/: one per NagPack per stack, with columns for Rule ID, Resource ID, Compliance status, Exception Reason, and Rule Level. Those CSVs are compliance evidence artifacts. They go into the quality management system alongside the test results and deployment records.

When a cdk-nag rule must be suppressed (because the rule doesn't apply to the specific context), the suppression is recorded in code with a mandatory reason string:

NagSuppressions.addResourceSuppressions(logBucket, [
  {
    id: 'AwsSolutions-S1',
    reason: 'Access logging bucket cannot log to itself - circular dependency'
  }
]);

That suppression is version-controlled, code-reviewed, and traceable. An auditor can search the codebase for every suppression, read the justification, and verify it was reviewed. Compare that to a manual process where someone unchecks a box in a spreadsheet.

The ThoughtWorks Technology Radar recognizes cdk-nag for identifying and reporting security and compliance issues in CDK applications. No GxP-specific NagPack exists yet, but the HIPAA and NIST packs overlap heavily with 21 CFR Part 11 and Annex 11 requirements. We supplemented with custom CDK Aspects for controls specific to our architecture.

Drift Detection: Maintaining the Validated State

Deploying compliant infrastructure is the easy part. Keeping it compliant after six months of production operations, console access, and incident response is where most teams fail. Someone modifies a security group through the console. An automated process changes a bucket policy. A team member creates a resource outside of CDK. The infrastructure drifts from its qualified state, and your IQ/OQ evidence no longer reflects reality.

AWS Config provides continuous configuration monitoring across 200+ resource types. We configured Config rules mapped to every IQ/OQ check: encryption enabled, public access blocked, VPC endpoints active, CloudTrail running. When a resource violates a rule, Config marks it NON_COMPLIANT and triggers an EventBridge event.

The drift response follows a severity classification:

• Security drift (encryption disabled, ports opened, public access enabled): Immediate auto-remediation via Config remediation actions, plus an automatic CAPA (Corrective and Preventive Action) opened in the quality system. This maps directly to ISO 14971 risk controls.
• Functional drift (resource deleted, configuration changed): Hold for human review. The drift is logged, the team is notified, and a CAPA is opened if the change was unauthorized.
• Cosmetic drift (tags, descriptions): Auto-remediate and log. No CAPA needed.

CloudFormation drift detection runs on a schedule and compares the deployed stack against the last deployed template. If someone changed a security group through the console, drift detection catches it. The combination of Config rules (continuous, per-resource) and CloudFormation drift detection (periodic, per-stack) provides overlapping coverage.

Per ISPE's GAMP IT Infrastructure Guide, the validated status of GxP applications can be compromised if the IT infrastructure is not maintained in a demonstrable state of control. Drift detection with automated remediation is that demonstrable state of control.

Infrastructure as Code and IEC 62304 Traceability

Under IEC 62304, infrastructure is a SOUP (Software of Unknown Provenance) item. The CDK code and its dependencies (AWS construct libraries, cdk-nag) carry SOUP classification. That means they need:

1. Version pinning: Every CDK construct library version is locked in package.json. No floating version ranges.
2. Risk assessment: The risk management file includes risk items for each infrastructure dependency. What happens if a CDK construct introduces a breaking change? What if a cdk-nag NagPack removes a rule?
3. Change control: Infrastructure changes follow the same change control process as application code. Every CDK modification goes through a pull request, gets reviewed, passes cdk-nag and assertion tests in CI, and produces a CloudFormation changeset that shows exactly what will change before deployment.

An FDA reviewer asks "how do you verify that patient data is encrypted at rest?" The answer is a chain: design requirement traces to CDK construct, traces to assertion test, traces to cdk-nag report, traces to PQ verification, traces to IQ report. Every artifact generated automatically, every one version-controlled.

Frequently Asked Questions

What is IQ OQ PQ validation?

IQ OQ PQ stands for Installation Qualification, Operational Qualification, and Performance Qualification. It is a three-stage framework for proving that infrastructure and systems work as specified. IQ verifies correct installation, OQ verifies correct operation within parameters, and PQ verifies correct performance under production conditions. For cloud-hosted medical devices, IaC tools like AWS CDK automate all three stages, generating qualification evidence on every deployment rather than through manual checklists.

Does GAMP 5 allow infrastructure as code?

Yes. GAMP 5 Second Edition (July 2022) explicitly endorses Infrastructure as Code as an approved provisioning method for GxP-compliant infrastructure. IaC-provisioned cloud infrastructure falls under GAMP Category 1 (Infrastructure Software), which requires qualification rather than full validation. Appendix M11 addresses cloud infrastructure specifically, and Appendix M12 introduces critical thinking as a replacement for prescriptive validation checklists.

What is cdk-nag used for?

cdk-nag is an open-source compliance tool for AWS CDK maintained by Amazon's cdklabs team. It validates CDK constructs against compliance rule sets (NagPacks) including HIPAA Security, NIST 800-53, and PCI DSS. Unsuppressed errors prevent deployment. It generates CSV compliance reports that serve as audit evidence. For medical device software, cdk-nag catches compliance violations like missing encryption or public access at synthesis time, before infrastructure is deployed.

How do you validate cloud infrastructure for medical devices?

Cloud infrastructure for medical devices is validated through a combination of IaC-based IQ/OQ/PQ (automated deployment verification, CDK assertion tests, post-deploy checks), continuous compliance monitoring (AWS Config rules, CloudFormation drift detection), and shift-left compliance scanning (cdk-nag NagPacks). The AWS GxP Systems whitepaper and GAMP 5 Second Edition both endorse this approach, with AWS reporting 30-40% reductions in qualification times compared to manual methods.

References

• AWS GxP Systems Whitepaper
• AWS GxP Compliance Solutions
• Computer Systems Validation on AWS
• cdk-nag GitHub Repository
• cdk-nag on AWS Prescriptive Guidance
• cdk-nag on ThoughtWorks Technology Radar
• AWS CDK Testing Documentation
• FDA Computer Software Assurance Guidance
• ISPE GAMP 5 Second Edition
• 21 CFR Part 11 — Electronic Records
• HIPAA Security Rule 164.312
• Montrium: Infrastructure as Code for Infrastructure Qualification