Describe what you actually do, in plain sentences: how third-party libraries are inventoried, how new ones are approved, how they are scanned, and how fixes are made. Management writes the description and the auditor tests it against evidence, so every sentence must be something you can prove with a record.
Who writes it and why wording matters
In a SOC 2 examination, management describes the system and its controls, and the independent CPA examines that description and tests the controls. If your description says something you do not do, the gap becomes a finding. If it understates, you lose credit for good practice.
This is a drafting problem. Good language is specific, bounded and testable.
Sentences that work
Use statements tied to a mechanism and a record:
- "Third-party libraries are declared in manifest files and pinned with lockfiles committed to version control."
- "Changes to dependencies are made through pull requests that require approval by an engineer other than the author before merge."
- "Automated tooling scans repositories for known vulnerabilities in dependencies and creates alerts that are triaged by the owning team."
- "Vulnerabilities are remediated according to the timelines in the vulnerability management policy. Exceptions are documented with an owner, a reason and a review date."
- "New direct dependencies are reviewed for license and maintenance status before approval."
Each has a clear test: the auditor can request a sample and look.
Phrases to avoid
| Avoid | Why | Try instead |
|---|---|---|
| "All dependencies are always up to date" | Never true, easy to disprove | "Dependencies are updated on a defined cadence" |
| "Zero known vulnerabilities" | Changes daily | "Known vulnerabilities are triaged per policy" |
| "Fully automated" | Hides the human steps | Name the human approval |
| "Continuous monitoring" without detail | Vague | State tool, scope and alert handling |
| "SOC 2 compliant" | A report is not a status you hold | "Under examination" or "report available" as accurate |
Keep it consistent across documents
Your description, policies, trust page and questionnaire answers should agree. A buyer or auditor who compares them will notice if the trust page promises daily scanning and the policy says weekly. Write the facts once, then reuse the wording.
What to include about boundaries
Say which third-party components are in scope: production libraries, build tooling, base images. Mention that hosted vendors are managed through a separate vendor process. If a category is out of scope, say so and give the reason.
Review it with the people who run the controls
Have an engineer read the dependency paragraph and mark every sentence true, partly true, or aspirational. Fix the aspirational ones by changing the practice or the words. Do this before the auditor reads it, not after.
Where Safeguard fits
Safeguard's SBOM, dependency scanning and compliance and evidence automation can give you records that back each sentence. It does not write your system description or replace your auditor. Free scan: https://gold.safeguard.sh/scan.
Quick check
Who owns the system description?
Management owns it. The auditor examines it. Draft it with the engineers who run the controls.
Should the description name specific tools?
It can, but tool names change. Describe the control and mechanism, and name tools only when the detail helps a reader.
Sources
Last reviewed: 19 October 2026.
