CSVtoCSAPractical Software Assurance
SearchSubscribe
Menu
PRACTITIONER METHOD

Practical software assurance playbook

SaaS Validation and Change Control

A practical route from intended use and supplier evidence to release impact, local testing, and maintenance of the validated state for software you cannot freeze.

Professional interpretationEducational practitioner method · Quality review required for case-specific use

Validation process

Apply the lifecycle controls

  1. 01

    Intended Use

    Assessment
    Name the workflows, records, decisions, users, sites, configurations, and exclusions in the customer-controlled boundary.
    Expected record
    Approved intended-use statement and boundary diagram.
  2. 02

    Supplier Assessment

    Assessment
    Determine which lifecycle, security, service, test, defect, and release evidence is inspectable and applicable.
    Expected record
    Supplier assessment with evidence references, limitations, and ownership.
  3. 03

    Configuration Risk

    Assessment
    Identify rules, roles, forms, reports, signatures, master data, and low-code elements whose behavior differs by customer.
    Expected record
    Configuration inventory linked to intended use and realistic failure modes.
  4. 04

    Data Integrity

    Assessment
    Identify the authoritative record, change history, retention, export, recovery, and customer-versus-supplier responsibilities.
    Expected record
    Record map, retention decision, audit-trail scope, and restore evidence.
  5. 05

    Interfaces

    Assessment
    Trace source, payload, transformation, destination, acknowledgment, retry, duplicate, and reconciliation behavior.
    Expected record
    Interface control specification and negative/recovery evidence.
  6. 06

    Testing

    Assessment
    use applicable supplier evidence and focus local challenge on configuration, integration, roles, critical workflows, and use conditions.
    Expected record
    Risk-based test record with supplier/local coverage rationale.
  7. 07

    Supplier Releases

    Assessment
    Separate irrelevant platform changes from shared-component, configuration, workflow, record, security, and integration impact.
    Expected record
    Release assessment with affected GxP functions and regression rationale.
  8. 08

    Change Assessment

    Assessment
    Assess cumulative change, open defects, local configuration changes, new integrations, and shifts in intended use.
    Expected record
    Approved impact assessment and risk-based validation evidence plan.
  9. 09

    Periodic Review

    Assessment
    Review incidents, access, supplier performance, evidence freshness, configuration drift, and unresolved actions.
    Expected record
    Validated-state review with reassessment criteria and decisions.

Release gate

Before the decision is defended

  • Critical workflows and interfaces are covered for the actual configuration.
  • Supplier evidence has a defined, reviewable scope.
  • Open defects and residual risks have named owners and conditions.
  • Change notification, monitoring, recovery, and reassessment responsibilities are explicit.

Scope and limitations

What this playbook does not establish

  • This playbook does not qualify a supplier or validate a SaaS product by itself.
  • Contract, privacy, cybersecurity, availability, and jurisdictional requirements need separate subject-matter review.
  • Release cadence does not remove the need for documented customer decisions.

Use applicable regulations, final guidance, organizational procedures, and subject-matter review for the actual system and jurisdiction.