They can. Security questionnaires, contract schedules, and trust pages often describe your dependency practices in specific terms. Before you retire or change a policy, find every place it was described to customers, check each statement against the merged policy, and update or confirm it. Ask counsel about contract wording.
Where the promises hide
Policies are rarely quoted only in the policy. They spread into other documents:
- Completed security questionnaires and due diligence answers
- Contract security schedules and data processing terms
- Public trust or security pages
- Sales decks and one pagers
- Responses to requests for proposals
- Support macros that answer security questions
- Commitments made in emails to a specific customer
After a merger there are two sets of these, one for each company.
Step 1: Collect them
Ask sales, customer success, legal, and support for every document that describes how you manage dependencies, patching, or licenses. A shared folder of past questionnaire answers is the best single source. Search it for phrases like "open source", "vulnerability", "patch", "SBOM", and "third party".
Step 2: Extract the statements
For each document, write down the exact claim. Examples of the kind of claim to look for: a stated fix timeline, a statement that dependencies are scanned on every build, a commitment to provide an SBOM on request, a promise to notify customers of certain issues.
Step 3: Check against the merged policy and reality
For each statement, answer two questions. Is it consistent with the merged policy? Is it true for both product lines today?
| Result | Action |
|---|---|
| Matches policy and practice | Keep |
| Matches policy, practice lags | Fix practice, or revise the wording |
| Policy is looser than the claim | Keep the stricter practice or update the claim with notice |
| Applies to a product that is being retired | Note the end date |
The risky row is the third: a customer was promised more than the merged policy delivers.
Step 4: Update wording carefully
Be specific and honest. Do not describe in-progress work as complete. Never state an audit, attestation, or certification as done unless it is, and you can show the report. If a contract has a clause that commits you to a given practice, speak to counsel before changing anything.
Step 5: Keep one source of truth
Create one approved set of statements about your dependency practices, with an owner, and have sales and support draw from it. A questionnaire answer written from memory by a new rep is how old claims return. See how to answer what is your MFA policy in a security review for the same idea applied to another control, and open source usage policy, what customers expect to see.
Try it yourself
Click through it at your own pace, or open it full screen. See how one internal control is tied to the requirements customers ask about.
Safeguard's compliance and evidence automation helps keep answers tied to records from your actual scans and gates.
Quick check
Do we have to notify customers when we change a policy?
It depends on your contracts. Ask your legal advisers, and review any clause that names a specific practice.
Who should own these statements?
One named owner, usually in security or compliance, with sales and support using the approved set.
Last reviewed: 19 October 2026.
