CASE STUDY · REGTECH / COMPLIANCE AUTOMATION
Automating SOC 2 evidence collection for a growing fintech.
- 8 weeksAudit preparation down from 8 weeks to 5 weeks, saving 3 weeks
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised growing fintech company. Name withheld under confidentiality.
5 integrations connected and 24 priority controls mapped to automated evidence. The integrations covered the cloud platform, the identity provider, the code repositories, the ticketing system and the HR system. Each control had an owner, a defined piece of evidence and a collection schedule.
- 1About 8 weeks of manual evidence gathering for each audit.
- 2A small team pulled access lists, change records, training logs and vendor reviews from many systems and stored them as screenshots and exports.
- 3Engineers were pulled away from product work for weeks.
- 4Each audit repeated the same hunt, and each time something was missed or out of date.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01The HR system exported records in a format that changed whenever an administrator edited a report template
Two weeks in, our collector began to silently drop leavers from the access-review comparison, which made the review look cleaner than it was. A dry-run comparison against the manual pack caught it. We switched to the system's documented interface rather than the report export, added a count check between source and store, and set an alert for any sudden drop in record numbers.
- PROBLEM 02We switched to the system's documented interface rather than the report export, added a count check between source and store, and set an alert for any sudden drop in record numbers
- PROBLEM 03A second hurdle came from ownership
Several controls depended on a team that was not part of the project, and when a check failed, the ticket sat unassigned. In the first month, a failed access check stayed open for days because nobody knew it was theirs. We added an owner field to every control, set a rule that no check could go live without a named person and a backup, and added a weekly list of open failures to the security meeting.
- PROBLEM 04Response times improved because the problem was clear and visible
03 · THE PROCESS
How we ran it.
- 01Weeks 1 to 2
Reviewed the previous audit's requests with the security lead and listed every piece of evidence requested. Ranked them by hours spent. Chose the 24 priority controls.
- 02Weeks 3 to 6
Built the five integrations one at a time, each with a demo and a check that it failed correctly when we broke the condition on purpose.
- 03Weeks 7 to 8
Ran a dry run using the prior audit's request list and compared automated evidence with the manual pack.
- 04After launch
Monthly review of failed checks and a short quarterly session with the compliance owner.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Evidence is collected all year, so the audit period is no longer a scramble.
- NOW 02
Access reviews run on a set schedule using the dashboard.
- NOW 03
Failed checks are triaged in the weekly security meeting, not discovered by an auditor.
- NOW 04
Customer questionnaires draw from the same evidence store, so answering them takes less time.
- 8 weeks
Audit preparation down from 8 weeks to 5 weeks, saving 3 weeks
05 · WHAT WE BUILT
How it works.
- Each integration used read-only credentials stored in a secrets manager and ran on a schedule.
- Collectors pulled raw records, such as user lists with sign-in settings and merged change requests with their approvals.
- They stored them in a locked evidence store with a timestamp and source.
- A mapping layer linked each record to the control it supports.
- Controls were evaluated by rules.
- For example, a rule might check that every active user has multi-factor sign-in, or that every merged change had a review.
- Controls after launch
- Collectors alert if they return no data, if record counts drop sharply or if a credential fails, so a broken integration cannot pass as a clean result. Credentials rotate on a schedule and are reviewed each quarter. The evidence store keeps its own access log.
- Handover
- We trained the security lead and two engineers to add a new collector from a template, write a new rule and read the failure log. The runbook covers what to do when an integration breaks, who to tell and how to document the gap for the auditor. The company now owns the code and the schedule.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- About 8 weeks of manual evidence gathering for each audit. A small team pulled access lists, change records, training logs and vendor reviews from many systems and stored them as screenshots and exports. Engineers were pulled away from product work for weeks. Each audit repeated the same hunt, and each time something was missed or out of date.
- What did Brandsmashers build?
- 5 integrations connected and 24 priority controls mapped to automated evidence. The integrations covered the cloud platform, the identity provider, the code repositories, the ticketing system and the HR system. Each control had an owner, a defined piece of evidence and a collection schedule.
- What were the results?
- Audit preparation down from 8 weeks to 5 weeks, saving 3 weeks.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
