Spend the first month on inventory and baseline, the second on review rules and written policy, and the third on running the controls and collecting evidence. By day 90 you should have operating dependency controls and dated records. Do not call yourself SOC 2 compliant until your auditor issues a report.
Month one: see what you have
Weeks 1 and 2. List every repository and service that is in scope. Confirm each has a manifest and a committed lockfile. Generate a component inventory.
Weeks 3 and 4. Run a baseline scan across all of them. Count findings by severity. Do not try to fix everything. The goal is knowing the size of the problem so policy numbers are honest.
Deliverables: repository list, inventory export, baseline findings summary.
Month two: decide and write
Weeks 5 and 6. Draft the vulnerability and dependency policy: fix timelines by severity, how new packages get approved, how exceptions are recorded, who owns what. Keep it to two pages.
Weeks 7 and 8. Turn the policy into settings. Protect the default branch and require review. Require status checks. Enable automated alerts and update pull requests. GitHub documents branch protection settings that include required reviews and required status checks, and Dependabot's two pull request types for security and version updates.
Deliverables: signed off policy, branch rules export, scanner configuration.
Month three: run it
Weeks 9 and 10. Operate the process for real. Triage alerts, open tickets, merge fixes through pull requests, record exceptions.
Weeks 11 and 12. Hold the first monthly dependency review. Sample five closed items and check each trail. Fix whatever is missing.
Week 13. Assemble the evidence folder: policies, settings exports, scan history, sampled tickets, review notes, all dated.
A checklist at day 90
| Item | Done |
|---|---|
| In scope repos listed and reconciled with scanner | |
| Lockfiles committed in each deployable repo | |
| Default branch protection exported with a date | |
| Fix timeline written and approved | |
| Exception records exist for anything late | |
| One monthly review completed with notes | |
| Five sampled trails verified |
What a Type 1 does and does not need
A Type 1 looks at the design of controls at a point in time, so what matters is that the controls exist and you can show them working. A later Type 2 will test operation over a period, so keep the same records going without a gap. Confirm exact expectations with your auditor, since firms differ.
Pitfalls
- Writing policy numbers aggressive enough to look good, then missing them in week ten.
- Treating the baseline scan as the control.
- Collecting screenshots without dates.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, policies and gates, and compliance and evidence automation can support each phase of this plan. It does not make you certified, and your auditor decides what is sufficient. Free baseline scan: https://gold.safeguard.sh/scan.
Quick check
Is 90 days enough for the whole SOC 2 Type 1?
This plan covers dependency controls only. The full effort includes many other areas, and timing depends on your auditor and scope.
Should I fix every baseline finding first?
No. Prioritize by severity and exposure, set the policy from what you learn, and record exceptions for the rest.
Sources
- GitHub Docs, About protected branches
- GitHub Docs, About Dependabot version updates
- AICPA and CIMA, SOC suite of services
Last reviewed: 19 October 2026.
