Changing compliance from blocker to asset: ISO 27001 and SOC 2 Type 2 from scratch to renewal
A case study from Aijutsu — the founder-led, coaching-informed, AI-leveraged technology practice serving Singapore founders and SMEs. Client's identity is withheld under confidentiality.
- Client
- A Singapore-headquartered B2B technology company (identity and industry withheld under confidentiality)
- Scale
- Seed funding, 5-10 employees, no certifications, no compliance function
- Certifications achieved
- ISO 27001 and SOC 2 Type 2 across 4 cycles including one renewal audit for ISO
- Compliance headcount
- No dedicated compliance hires — built alongside infrastructure and product
- Tooling
- Drata (compliance automation and trust center), Jira (due diligence escalation workflow), internal FAQ bot for sales
- Key result
- ISO 27001 and SOC 2 Type 2 certifications maintained, 2-person team handling an average of 3 due diligence questionnaires per week in addition to other technical duties
Compliance ceased to block enterprise deals once it became a property of how the company already operated — certification reduced to documentation of existing practice, and due diligence became a largely self-serve sales process.
The challenge: selling to enterprises that audit their vendors
The company's buyers were large, security-conscious enterprises whose procurement processes subject every vendor to detailed scrutiny. Every enterprise deal arrived with the same gate in front of it: vendor due diligence. Security questionnaires running to hundreds of items. Requests for certifications the company did not yet hold. Contractual demands about data handling across jurisdictions.
For an early-stage company, this stage of procurement frequently determines whether a deal proceeds at all. A typical sequence: the commercial conversation progresses well, a questionnaire arrives, several weeks pass while engineers are diverted from product work to answer it, gaps surface, remediation commitments are made, and the opportunity loses momentum. Because the company held itself to a high security standard, a weak or slow answer also carried a credibility cost beyond the procurement delay itself.
The constraints mirrored the infrastructure story told in the companion study:
- No compliance team, and no prospect of a dedicated hire. Whatever control environment existed would be owned by the same small group responsible for infrastructure — there was no separate function to hand anything to yet.
- Certification was a commercial requirement. Enterprise procurement in [the US, EU, and APAC] increasingly treats SOC 2 Type 2 and ISO 27001 as preconditions for vendor onboarding.
- The company could not afford compliance theatre. A paper-only ISMS that diverged from actual practice would collapse under a Type 2 audit, which observes operation over time rather than at a point in time.
The approach: make the controls real, then make them self-serve
1. Build the control environment before the audit exists
As described in the companion study, the technology stack was built compliance-aware from day one: centralised identity and access management, audit logging by default, environment separation, encryption in transit and at rest, and infrastructure defined entirely as code. These measures were adopted because they are how a small team operates safely; their audit value followed as a consequence. When certification was pursued, the majority of technical controls already existed and already generated their own evidence.
The general principle: the cheapest compliance programme is one that documents reality rather than constructing a parallel one.
2. Treat ISO 27001 and SOC 2 as one programme, not two
ISO 27001 and SOC 2 Type 2 overlap substantially in the controls they examine — access management, change management, incident response, vendor management, business continuity. Running them as separate projects doubles the work; running them as one control set with two reporting outputs roughly halves it. We mapped controls once and evidenced them for both frameworks.
3. Automate evidence collection
A Type 2 audit examines whether controls operated over a period of months. Collecting that evidence manually — screenshots, exports, ticket reviews — consumes a disproportionate share of a small team's capacity.
We deployed Drata as the compliance automation layer, integrating it with the systems of record: Microsoft for identity, AWS for cloud configuration, Linear for change management, Github for software development lifecycles.
Control monitoring became continuous rather than annual: Drata tracked control status against both frameworks from the same integrations, flagged drift as it occurred rather than at audit time, and produced auditor-ready evidence directly from the connected systems. Combined with the infrastructure-as-code foundation, the audit observation period required little-to-no separate preparation effort; the company simply continued operating throughout audits.
4. Publish a self-serve trust center
Using Drata's Trust Center feature, the company stood up a public, self-serve destination where prospects and customers could access sensitive documents such as the ISO 27001 and SOC 2 certifications and management reports, and penetration testing reports.
The commercial effect was that due diligence could begin before anyone asked: sales shared the trust center link early in the conversation, a meaningful share of standard questions never became questionnaire items, and procurement teams could verify certification status without an email exchange.
From week-long email chains, implementation of the Trust Center reduced this to a single email sharing the link to the Trust Center page and then approving the request.
5. Equip the sales team with an FAQ bot and a defined escalation path
Even with a Trust Center in place, questionnaires and one-off security questions continued to reach the sales team, and each had historically required an engineer's involvement. We centralised the accumulated due diligence knowledge into an internal FAQ bot for the sales team. The bot answered common questions directly and pointed sales to the authoritative source for the remainder: company policies, audit certifications, the Trust Center, and the standing answers to frequently asked due diligence items.
The workflow also had a defined escalation path. Anything the bot could not answer — novel questions, customer-specific contractual asks, anything requiring judgment — was escalated via JIRA to engineering leads. Resolved escalations were folded back into the FAQ corpus, so the bot's coverage grew with every deal and the same question never escalated twice.
The resulting division of labour: sales self-served the routine 90% of due diligence, engineering leads handled genuinely novel questions through a trackable queue, and general engineering's involvement in routine due diligence was eliminated.
6. Make policy match practice — then keep them matched
Policies were written to describe what the team actually did, in language the team actually used, and were kept short enough to be read. Where practice was inadequate, the practice was fixed first and the policy written second.
The ISMS review cycle was tied to existing operational rhythms rather than a separate compliance calendar, with Drata's continuous monitoring acting as the early-warning system between reviews, so the system remained in continuous operation between audits.
The execution: sequence of the programme
Phase one: Gap assessment. The existing environment was assessed against both frameworks together. Because the stack had been built compliance-aware, the gaps were concentrated in policies around financial guardrails, business continuity plans outside of the technology stack, and HR rather than technical controls.
Phase two: Remediation and formalisation. Drata deployed and integrated with the systems of record; remaining controls implemented; policy set written against actual practice; risk assessment and ISMS structures established for ISO 27001; the SOC 2 observation window opened.
Phase three: Audit and certification. A non-event given the automations and guardrails that were in place. ISO 27001 audits happened over a week at the auditor's request, while SOC 2 audits happened asynchronously given auditors' visibility into our evidences stored in Drata.
Phase four: Operation and the sales-side machinery. The programme moved to steady state: continuous control monitoring in Drata, scheduled access reviews, surveillance audits. The trust center went live, the sales FAQ bot was rolled out, and the JIRA escalation workflow connected sales to the engineering function. Due diligence operated from this point as a routine, measurable process.
Throughout the process, compliance was run alongside engineering responsibilities with no dedicated compliance hire. At steady state, the entire programme — controls, policies, Drata, its Trust Center, and the escalation queue — was handed off to the engineering leads, and continued operating.
What did not go smoothly
Integration with Sales. The Sales function of most organisations are go-getters who don't have time to fumble around configuration switches and understand processes. When the deal is on the table, they need the information in front of them there and then. This resulted in teething issues while educating the team about where data is stored and how to access what they need to without a DM to an engineering team member.
The results
- ISO 27001 and SOC 2 Type 2 achieved, operated and renewed once since, with no dedicated compliance headcount.
- The full programme was handed off back to the team — certifications, policies, Drata, Trust Center, and escalation queue — and continued operating, demonstrating that the system ran on automation and a successful transformation journey process.
- Enterprise due diligence became self-serve: Trust Center for prospects, FAQ bot for sales, JIRA escalation to the platform team for the exceptions.
- Compliance ceased to be a deal blocker: Reliance on Engineering's response times which are historically in the 1-2 hours range no longer blocked Sales.
What this means if you're running a startup or SME
Put simply: compliance is inexpensive when it documents how a company already operates, and expensive when it must construct practices that should already have existed.
A common failure mode is to begin compliance work only when a major customer demands certification: policies are drafted that describe practices the company does not follow, controls are introduced under deadline pressure, and engineers absorb the evidence-collection burden. The approach demonstrated here costs considerably less, but it requires three things: an operating environment built with the eventual audit in mind, automation carrying the evidence work (tools like Drata and alternatives pay off in proportion to the quality of the systems they monitor), and someone senior who has been through these audits before and knows what will actually be examined.
This is the work we do at Aijutsu, the founder-led, coaching-informed, AI-leveraged technology practice serving Singapore founders and SMEs: compliance readiness and adoption sprints for ISO 27001 and SOC 2, alongside senior technical advisory, cloud, and AI. If enterprise customers are beginning to ask about your certifications, that outcome is avoidable.
Book a diagnostic conversation: [email protected]
Frequently Asked Questions
How long does it take a startup to get SOC 2 Type 2?
A SOC 2 Type 2 report requires an observation window — commonly 12 months — during which controls must demonstrably operate, plus preparation and audit time. The company in this case completed the programme in 6 months because most technical controls already existed and we underwent a manual interview process at the start for the initial certification; companies starting from scratch typically need 6 months or more.
Should a startup do ISO 27001 or SOC 2 first?
It depends on the customer base: SOC 2 dominates US enterprise procurement, while ISO 27001 carries more weight in Europe and Asia-Pacific. Because the two frameworks overlap heavily, the most efficient approach — used in this case — is to build one control set and certify against both, sequencing audits by commercial priority.
Do you need a compliance team to get ISO 27001 and SOC 2?
Not at early stage. A startup with 10 people achieved and maintained both certifications with no dedicated compliance headcount: compliance was built by educating the engineers running the platform on the requirements, automated with Drata for evidence collection, and ultimately handed off as a shared responsibility to lead level engineers. What is required is senior ownership — someone accountable who has seen these audits before.
What is a Trust Center and should a startup have one?
A Trust Center is a self-serve page where prospects and customers access a company's certifications, security policies, subprocessor lists, and audit reports (with gating for sensitive documents). For any startup selling to enterprises, it is one of the highest-leverage compliance investments: in this case it allowed due diligence to begin before anyone asked and eliminated a meaningful share of questionnaire traffic.
How do you answer enterprise security questionnaires faster?
Make the answers self-serve in layers: a public Trust Center for standard verification, an internal FAQ bot so the sales team can answer common due diligence questions and locate policies and certifications without involving engineers, and a defined escalation path — in this case via JIRA to the engineering team — for genuinely novel questions, with resolved escalations fed back into the FAQ. Turnaround in this case fell from hours to seconds.
Does compliance actually help close enterprise deals?
Yes — increasingly it gates them. Enterprise procurement in the US, EU, and Asia-Pacific commonly treats SOC 2 Type 2 or ISO 27001 as preconditions for vendor onboarding. In this case, certification combined with the self-serve due diligence machinery converted the stage where deals previously stalled into a routine step in the sales process.
Aijutsu is a founder-led, coaching-informed, AI-leveraged technology practice in Singapore. Its founder previously held senior technology leadership at the company described in this case study, where this work was carried out.