Design and Configuration Specification (DS)

This is a ready-to-use Design and Configuration Specification. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your architecture diagrams and code repositories, and route it through your normal document control, review, and approval. The DS is where the functional spec stops describing what the system must do and starts recording exactly how it is built and set: the architecture, the as-configured value of every configurable item, the custom code, the infrastructure it runs on, and the security and role model. It is the document an installation and configuration test reads against, and the document an inspector reads to see that the live system matches what was approved. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This specification records how the system <<FILL: system name and version>> is designed, configured, coded, and deployed to meet the functions defined in functional specification <<FILL: FS-ID>>, which in turn satisfies user requirements specification <<FILL: URS-ID>>. It captures the as-built architecture, the exact value set for every configurable item, any custom code, the infrastructure platform, and the security and role configuration. The objective is a single approved baseline that the installation and configuration verification tests against, that change control protects, and that an inspector can compare against the live system to confirm the two still match.

2. Scope

This DS covers the design and as-configured state of <<FILL: system name>> as deployed for <<FILL: business process>> at <<FILL: site(s)>>. It includes the architecture in section 5, the configuration items in section 6, the custom code in section 7, the infrastructure in section 8, and the security and role configuration in section 9. It does not cover <<FILL: out-of-scope items, e.g. the underlying corporate network, the virtualization host, or processes handled by SYSTEM-Y>>, which are governed by <<FILL: cross-reference IDs>>. Where a configuration item is owned and qualified by a separate platform or supplier, it is referenced here, not redefined.

3. Definitions and conventions

• Configurable item: a setting, parameter, workflow step, template, calculation, report, or limit that is changed through the application’s intended configuration interface, without altering source code.
• Custom code: any script, macro, formula, stored procedure, custom report, calculated field, integration interface, or bespoke component written or modified for this implementation, beyond the supplier’s standard, configurable product.
• Configuration baseline: the complete, approved set of values in section 6 that defines the validated state. Any change to a value in the baseline goes through change control.
• GAMP category: the GAMP 5 software classification (3 standard, 4 configured, 5 custom) that sets the rigor of design documentation and testing. A category 4 system is configured; a category 5 system contains custom code and needs design and code review of that code.
• As-built / as-configured: the actual state of the deployed system at the effective date, not the intended or default state.

Each design element and configuration item carries a unique, stable ID (for example DS-CONF-012) and a trace to the functional specification item it satisfies. IDs are never reused; superseded items are retired, not renumbered.

4. Responsibilities

5. System architecture

Describe the system as deployed: the tiers, the components, the data stores, the interfaces, and the boundary. Attach the architecture diagram and the data flow diagram. State the GAMP category and the rationale, because it sets how much of sections 6, 7, and 9 you must document and test.

State the GAMP category here and justify it: a configured product with no bespoke code is category 4; the moment a calculated field, custom report, macro, or interface is written, the relevant component is category 5 and section 7 applies.

6. Configuration items (the as-configured baseline)

This is the heart of the DS. List every configurable item that affects GxP function, data integrity, security, or a regulated calculation, and record its exact set value. Do not write “as per vendor default”; record the value. Group by configuration area so the installation and configuration verification can step through it. Every safety-, data-, or decision-relevant item traces to a functional specification item and will be verified in the configuration test.

State the source of record for the baseline: the table above is authoritative; if a configuration-export file is the operational record, name it and its location, and reconcile it to this table at each change. Do not let an undocumented live setting drift away from the approved value.

7. Custom code

If the system is GAMP category 4 with no bespoke code, state that explicitly and mark this section “Not applicable, no custom code.” If any custom code exists (a calculated field, a macro, a custom report, a stored procedure, an integration interface, a script), each component is listed and is subject to design and code review. Standard, unmodified supplier product is not custom code.

Code-review notes to capture for each component: that the code meets the stated requirement, that error and exception handling is present, that there is no hard-coded credential, that inputs are validated, and that the version under review is the version deployed. Source is version-controlled; the deployed binary or script traces to a specific repository tag.

8. Infrastructure and environments

Record the platform the application runs on and the environments used, so the installation verification has something to confirm against and so the validated-state baseline includes the stack, not just the application.

Where the platform is a qualified shared service (for example a qualified hosting platform or a database service under its own IQ), reference that qualification rather than re-qualifying it here, and confirm the application’s reliance on it is in scope.

9. Security and role configuration

Record the access-control model exactly as configured: the roles, the privileges each role holds, the separation between conflicting duties, and the application-level controls that satisfy 21 CFR Part 11 and EU GMP Annex 11. This section is read directly by the access-control test.

9.1 Role-to-privilege model

9.2 Application-level security configuration

State whether administrators can edit GxP data or audit trails; the answer should be no, and where the product cannot fully prevent it, the procedural control and its monitoring are stated.

10. Traceability

Every configuration item, every custom-code component, and every security setting in this DS traces upward to a functional specification item (and through it to a user requirement) and downward to the qualification test that verifies it. The traceability matrix <<FILL: matrix ID>> is the authoritative cross-reference; the per-row “Traces to FS” and “Verified in” columns above are the working trace. No GxP-relevant configuration item exists in the live system without an entry here, and no entry here is left unverified.

11. Change control

This DS is the configuration baseline. After approval, any change to the architecture, a configuration value, custom code, the infrastructure stack, or the security model is made through change control per <<FILL: change control SOP-ID>>. The change record states the item, the old value, the new value, the reason, the impact and regression assessment, the re-test performed, and the DS version updated. The DS is reissued so its as-configured state always matches production. A live setting that differs from the approved DS value, with no change record, is a finding.

12. Acceptance criteria

This DS is acceptable for use when all of the following are true:

• The architecture and GAMP category are stated, justified, and consistent with the FS.
• Every GxP-relevant configurable item is listed with its exact set value, not a “default” reference, and traces to an FS item and a verification test.
• All custom code is identified, version-controlled, and has design and code review records, or the section is justified as not applicable.
• The infrastructure stack and environments are recorded, with platform qualification referenced.
• The role-to-privilege model and Part 11 / Annex 11 security settings are recorded, with separation of duties shown.
• The document is traceable, under change control, reviewed, signed, dated, and approved.

13. References

21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems). EU GMP Annex 15 (Qualification and Validation), 2015 revision. ISPE GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (2nd edition). FDA Guidance, Computer Software Assurance for Production and Quality Management System Software (issued 3 February 2026, superseding the 24 September 2025 final). PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments. ICH Q9, Quality Risk Management. IEC 62304 (medical device software lifecycle), where the system is or contains a medical device. 21 CFR Part 820 (QMSR), effective 2 February 2026, incorporating ISO 13485:2016 by reference, where applicable.

Confirm the current version and clause numbers of each reference before issue.

14. Attachments

15. Revision history

16. Approvals

Filled specimen

The following shows the configuration, custom-code, and security sections completed for an example laboratory information management system, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

Configuration baseline (extract):

Custom code:

Security model:

In this example the team recorded the real timeout value rather than “vendor default,” traced each setting to an FS item and an OQ test, treated the one calculation script and the one interface as category 5 with full code review, and showed that an administrator cannot approve data and a reviewer cannot approve their own result. That is exactly the configuration evidence a reviewer is expected to see, and it is what the installation and configuration verification reads against.

Common inspection findings this specification prevents

• Configuration values recorded as “as per vendor default” with no actual value, so no one can tell what the validated state is or whether production still matches it.
• The live system holds settings that differ from the approved specification, with no change record explaining the difference.
• Custom code (a calculated field, a macro, a custom report, an interface) present in production but not identified, with no design or code review, so the system is treated as configured-only when it is actually custom.
• An audit-trail, timeout, lockout, or signature setting claimed as “configured” with no value recorded and nothing for the qualification test to verify.
• No traceability from a configuration item to the requirement it satisfies or the test that verified it.
• Administrators able to enter or approve GxP data, or to edit the audit trail, with no segregation of duties and no compensating control.
• The infrastructure stack and environments left undocumented, so the validated state covers the application but not the platform it depends on.

How to adapt this specification

1. Set your document number, owner, GAMP category, and effective date in the header, and link the URS, FS, and traceability matrix.
2. Replace the architecture in section 5 with your real tiers, interfaces, hosting model, and diagrams, and justify your GAMP category.
3. Record the exact as-configured value of every GxP-relevant item in section 6; remove the example rows that do not apply and add the configuration areas your product actually has.
4. If you have no custom code, mark section 7 not applicable with a justification; if you do, list every component with its repository, version, and review records.
5. Fill the infrastructure and environments in section 8, and reference platform qualification rather than re-qualifying a shared service.
6. Build the role-to-privilege model in section 9 from your actual roles and confirm separation of duties and the Part 11 / Annex 11 settings.
7. Point the cross-references in sections 8 and 11 to your real backup, DR, and change control procedures.
8. Confirm every regulation in section 13 against the current published version before issue.