Such changes also apply to patches and other “less direct” changes!
We’ve mostly been talking about internally-developed software here, but change impacts the validated state so they, too, need to be well-controlled.
Critical to Every Application
We’ll go into greater detail on change control later but suffice to say that change control is critical to every application, regardless of whether it was developed internally, custom developed externally, or purchased as “shrink wrap” software.
Normally, the controls in place include:
- Getting a copy of the code
- Tying the changes to the change authorization
- Having a peer review confirm the changes are as authorized and don’t appear to break anything
- Having the developer test the change
- And then provide information showing that the change did what was authorized and didn’t break anything.
Wow, that’s good software engineering!
Changes are typically amassed before making a new software release unless the change is to correct a critical bug and even then, maybe additional changes that have been piling up can be included in the release.
Re-Validation
This is why we mentioned the release documentation in the discussion previously.
It’s critical that validation engineers understand what changes went into a release to enable a proper re-validation.
You don’t necessarily need to see the specific code changes, but you need assurance that the controls are in place to make sure that only the authorized changes were in the release and all the changes in the release are identified.
