Start with the obligations that apply to you by law or by contract, then the controls every framework shares, then the attestations buyers ask for. For most early fintech teams the first ninety days go to MFA, encryption, an asset and data inventory, a vendor list, an incident plan and a testing calendar.
Three questions that sort the work
- What is mandatory for our business type and markets? Counsel answers this. For some US financial institutions the FTC Safeguards Rule applies, and for card data the PCI rules apply through your processor and acquirer.
- What do our buyers ask for? Look at the last ten questionnaires. Tally the topics.
- What would hurt most if it failed? Usually customer money movement, credentials and personal data.
The overlap between the three is your first list.
The shared core
Most regimes ask for the same basics, and the FTC Safeguards summary is a good example of the list: a named owner for the program, a written risk assessment, MFA, encryption in transit and at rest, access controls, a data inventory, logging, change management, testing, training, vendor oversight and a written incident plan.
Build these once, with evidence, and you can reuse them for several asks.
A sequence that works
Weeks 1 to 2. Name the owner. Inventory systems and where customer data lives. Turn on MFA everywhere it is missing.
Weeks 3 to 5. Confirm encryption in transit and at rest. Start the vendor register. Put logging and retention in place for core systems.
Weeks 6 to 8. Write the incident plan and run a short drill. Set the testing calendar: scans and a penetration test.
Weeks 9 to 12. Add dependency scanning and an SBOM to the build, with a policy gate. Run a first training session. Draft the board or leadership report.
Notification clocks
Learn the clocks that apply before you need them. For example the FTC rule asks for notice no later than 30 days after discovery of a qualifying event, and GDPR sets 72 hours for notifying a supervisory authority where it applies. Check which rules cover you.
Attestations and reports
A report from an independent auditor is something you pursue for buyers, not instead of the basics. Do not describe a report as complete before it is issued, and do not call an attestation a certification.
Common mistakes
- Buying tools before naming an owner
- Spreadsheets of policies with no evidence behind them
- Treating the processor's compliance as your own
- Forgetting engineering dependencies and build tools in the inventory
Safeguard's SBOM and dependency scanning, policies and gates, and compliance evidence automation fit the later weeks. A free scan is at gold.safeguard.sh/scan.
Quick check
Should we start with the audit report buyers ask for?
Usually no. Build the controls first, because the report will test them. Starting with the report means documenting controls that do not exist yet.
Sources
Last reviewed: 19 October 2026.
