GRC Perspective

The incident at PermanentCurePharmaGiant SARL highlights how third-party software changes must be governed with the same discipline as internal changes. The outcome demonstrates the importance of structured change management, configuration management, integration testing, and vendor assurance in regulated environments.

We are focusing the solution on GRC pillars — especially Change Management, Configuration Management and Vendor Management / Third-Party Risk Management.

1. Change Management for Third-Party Software

Every software update introduces change. Third-party software updates must be treated as formal change events.

In this case, the laboratory analysis software upgrade altered file-handling behavior. That change required classification, impact analysis, and evidence-based approval.

A mature change management process ensures that:

  1. Third-party updates are categorised by risk and impact
  2. Security impact is reviewed alongside functional impact
  3. Approval is granted based on testing evidence rather than historical trust
Outcome

Change management establishes accountability before software reaches production.

2. Configuration Management as a Control Anchor

Configuration management preserves stability across environments. Laboratory analysis software forms part of the application configuration baseline. Each update must align with defined configuration expectations.

Effective configuration management includes:

  1. Documented baselines for file types, sizes, and input structures
  2. Verification that updates preserve expected runtime behavior
  3. Confirmation that application safeguards remain intact after integration
  4. Configuration integrity provides predictability across releases

3. Integration Testing Beyond Functional Validation

Integration testing validates behavior in the client's environment. Functional testing confirms that laboratory workflows operate correctly. Security-focused integration testing confirms that software behaves safely under real operating conditions.

a) Controlled Sandbox Environment

  • Vendor updates are first deployed in a sandbox or pre-production environment
  • The environment mirrors production architecture and data flows
  • Observations are documented before release approval

b) Risk-Based Test Coverage

Integration tests cover:

  • File upload behavior
  • Boundary conditions such as file size and format
  • Input handling and processing logic
  • Unexpected execution paths

This testing reflects how the software is used, not only how it is designed.

c) Deployment Exit Criteria

Production deployment follows a defined checklist:

  • Internal test coverage is reviewed against vendor test scope
  • Differences between vendor testing and internal testing are documented
  • Security and application owners confirm readiness

4. Vendor SLA and Contractual Assurance

For software suppliers, SLAs must include explicit requirements around security testing and disclosure. Effective SLAs ensure:

  • Submission of complete third-party testing reports
  • Visibility into test scope, methodology, and exclusions
  • Timely disclosure of identified vulnerabilities
  • Clear notification timelines for hotfixes and corrective actions
Control Signal

Contracts reinforce transparency across the supply chain. Vendor testing becomes auditable evidence at change approval time.

5. Oversight of Vendor-Engaged Third Parties

When vendors rely on third-party testing providers, oversight remains essential. Best practice includes:

  • Awareness of who performs testing
  • Understanding what tests are conducted
  • Review of findings and limitations
  • Alignment on residual risks

Accountability remains end-to-end, regardless of outsourcing.

6. Event-Driven Risk Assessment

Each third-party software update triggers a focused review of:

  • Data confidentiality impact
  • Integrity of laboratory outputs
  • Exposure introduced by new functionality
  • Monitoring and detection considerations

Event-driven risk assessment keeps risk registers aligned with reality.

Closing Perspective

Third-party software becomes production-ready through governance, testing, and verification.

Strong outcomes emerge when:

  • Change management sets expectations
  • Configuration management preserves stability
  • Integration testing validates real-world behavior
  • Vendor contracts enforce transparency
Back to Problem Statement More Case Studies