Start with foundations that answer most questionnaire lines, then build evidence, then independent testing, then a formal attestation if buyers ask for one. A four quarter plan is realistic for a small team. Order matters more than speed, because early steps feed every later one.
Quarter 1: foundations
Goal: be able to answer the common questions truthfully.
- Name an owner for security, even part time.
- Write the short policy set: access control, incident response, change management, vendor management, data retention.
- Enforce single sign-on and multi-factor authentication for staff.
- Inventory systems, data stores and subprocessors.
- Turn on logging for production access and admin actions.
- Draw the data flow diagram buyers will ask for. See what belongs in a security architecture diagram.
Outcome: a first answer library and a one page security summary.
Quarter 2: evidence
Goal: prove the policies run.
- Record access reviews on a schedule.
- Keep change records tied to code review. The NIST SSDF, which recommends practices to reduce vulnerabilities in released software and gives buyers and suppliers a common vocabulary, is a useful checklist for this work.
- Run dependency and code scans in the pipeline and keep results.
- Train staff and keep completion records.
- Test backups and record the restore.
- Publish a subprocessor list and security page.
Outcome: an evidence folder organized by control, updated through the quarter. See evidence folder naming and structure for audits.
Quarter 3: independent testing
Goal: have a third party view of your product.
- Commission a penetration test with scope covering authentication, tenant separation and the API.
- Fix findings and arrange a retest.
- Run a tabletop incident exercise and record decisions.
- Draft a vulnerability disclosure policy and security.txt file.
- Prepare a test summary and tester letter for buyers.
Outcome: a shareable summary and proof that findings were closed.
Quarter 4: attestation, if buyers ask
Goal: decide whether a formal report is worth it now.
Some buyers ask for a SOC 2 report or an ISO certificate. Others accept a questionnaire with evidence. Look at your pipeline: if several deals name the same report, plan for it. A SOC 2 report is an attestation by an independent auditor, not a certification you can grant yourself, and a Type 1 report speaks to control design at a point in time. Read SOC 2 Type 1 versus Type 2 before choosing.
During any audit period, state your status exactly: "audit in progress" until a report exists.
A table of dependencies
| Step | Needs first |
|---|---|
| Access review evidence | Staff SSO and a user inventory |
| Pen test | Stable scope and a staging environment |
| Retest evidence | Fixed findings tracked in tickets |
| Audit | Several months of operating evidence |
Keep the roadmap honest
Show only what you have done in buyer facing material. A roadmap item is a plan, and it should be labeled as one. Use the same plan to answer "when will you have X" with a date you control.
Try it yourself
Open the framework mapping demo and see how one piece of evidence can map to several framework controls. This is the reuse that makes a four quarter plan efficient.
Click through it at your own pace, or open it full screen.
Safeguard offers compliance and evidence automation along with SBOM and dependency scanning, which can feed the second quarter's evidence work. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can a company skip straight to an audit?
You can, but audits go smoother when policies already run and evidence exists. Skipping foundations often turns an audit into a scramble.
Do we need all four quarters before selling to enterprises?
No. Many deals proceed after the first two quarters with good answers and evidence. Let your pipeline set the priority.
Sources
Last reviewed: 19 October 2026.
