Computer system assurance.

1Assurance answers one question for each release.

The question is whether there is enough objective evidence, proportionate to risk, to rely on this configuration of the system for its intended use.

That question is obscured when validation is organised around document names. The inventory sits in one spreadsheet, requirements in another, supplier evidence in a portal, tests in PDFs, configuration in tickets and release approval in email. The package can look complete while the production configuration has already moved on.

1.1Why teams choose Seal for computer system assurance

Traditional CSV validates a system once, around a document package, and then treats every change as a new validation project, so teams either freeze the configuration or let the package drift from what is deployed. Seal keeps the production configuration, the functions that matter, the evidence relied upon and the changes that challenge it in one lifecycle, so each change is a new release with its own risk assessment, test evidence and approval. Validation moves with the system instead of stopping it.

The same records can hold the assurance lifecycle for other regulated systems, including laboratory, manufacturing and quality systems, and for Seal’s own configuration, where your team still assesses and approves the configuration and its intended use. Reviewers can see why the system is trusted today, not only that a package was approved years ago.

2Define the system by what it is relied upon to do.

The regulated system is the unit of control. Its record defines the product, service model, owners, supplier, hosting, interfaces, data, users, electronic records and signatures, and lifecycle state. An inventory is not a list of application names: separate instances, tenants, modules and configurations can carry different risk and evidence, even from the same supplier.

Intended use draws the assurance boundary. It states which regulated decisions the system supports, who uses it and where, the records it creates and the limits beyond which it is not relied upon. These statements are versioned and approved. The boundary prevents two common failures: validating every product feature as if it were GxP-critical, and overlooking a small configured function that directly affects product quality or data integrity.

3Assess risk at the level of functions and failure modes.

Risk is assessed where harm can occur. Each function connects its intended behaviour, failure modes, detectability, patient or product impact, data-integrity impact and existing safeguards. Classification sets the depth and independence of the assurance work; it does not assign a fixed document set.¹ FDA’s Computer Software Assurance guidance takes the same position for medical-device production and quality system software, asking for objective evidence appropriate to the risk of the software feature, function or operation.²

Requirements follow the same proportion. Critical controls need explicit expected behaviour. Lower-risk workflow and usability concerns can be described through intended use, configuration, acceptance criteria or test charters instead of an inflated requirements catalogue. Each requirement links forward to configuration and evidence and back to its rationale, so orphan requirements and tests are visible during the work rather than in a trace matrix exported at the end.

4Assess supplier evidence against the claims it supports.

Supplier development controls, certifications, testing, release notes, service history, recovery and incident response can reduce duplicated work once their relevance and reliability are assessed. Seal records which claim each supplier artefact supports, its scope and version, who evaluated it, the gaps found, the compensating work and when it must be re-evaluated. A SOC report in a folder is not automatically validation evidence.

5Choose the strongest evidence for the effort.

Assurance can combine supplier evidence, automated checks, scripted and limited scripted tests, unscripted and exploratory testing, inspection, analysis and production monitoring. The strategy states why each technique suits the function and its risk.

Swipe to see the full diagram →

Evidence can be concise, but it must still identify the tester, environment, date, activity, result and any observed failure. An exploratory charter defines the mission, scope, risks, data and timebox; execution records observations, anomalies and the tester’s conclusion. Unscripted does not mean undocumented: it replaces prescribed keystrokes with skilled investigation where that gives stronger evidence. The build, configuration, interfaces, data set and accounts accompany each execution, so a passing test cannot be carried forward if it cannot be tied to the relevant state.

Each unexpected result connects to the function, evidence, severity, impact, correction, retest and disposition, and known supplier defects enter the same review. Acceptance can include a documented limitation and a compensating control, but only when its operational owner and monitoring are explicit.

6Release against a fixed configuration baseline.

Roles, permissions, workflows, fields, calculations, reports, integrations, master data, retention rules, signatures and audit-trail settings form a controlled configuration baseline.³ A test performed against a different tenant, feature flag, interface mapping or configuration version cannot silently qualify it.

The release brings together intended use, current risk, supplier assessment, requirements, configuration, testing, open anomalies, procedures, training and operational readiness. Approval fixes the accepted versions and rationale, and deployment confirmation checks that production matches the released baseline before regulated use begins.

7Assess change from what moved, and learn from what happens in use.

A supplier release, configuration update, integration mapping, role change, procedure revision or new intended use identifies the affected functions, risks, evidence and downstream controls.³ The impact assessment recommends reuse, focused regression, new testing, procedure or training action, or full requalification, and records why unaffected evidence remains valid.

Cloud systems may change more often than traditional validation projects allow for. The release policy covers the service model, tenant controls, feature enablement, supplier notification, sandbox availability, rollback and monitoring. Release-by-release evidence stays connected without rewriting the validation plan each time, and emergency changes have a controlled path with retrospective obligations.

Incidents feed back into the same lifecycle. A service interruption, incorrect behaviour, access issue or integration failure identifies the affected functions, records, time range and validation follow-up, and recurring failures raise function risk for the next test strategy. Periodic review weighs releases, configuration, access, incidents, backup and restore, supplier performance and open risks, and can conclude that the system continues, needs remediation or revalidation, or should be retired. Retiring an application is separate from retiring the obligation to keep and retrieve its records, audit trails and signatures.

8Prove one difficult release end to end.

Start with one configured cloud system and follow it through inventory, intended use, critical-function assessment, supplier review, baseline, risk-based strategy, scripted and exploratory testing, an anomaly, release, production verification, a supplier update, focused regression, an incident and periodic review.

Include supplier testing reused with justification, a feature excluded from GxP scope, a high-risk calculation, a role-permission failure, configuration drift between test and production, and an accepted known defect with a compensating control. The first release should show exactly what was trusted, what remains uncertain and why the current production state is authorised.