ISO 27001 without the parallel paperwork universe
We build ISMS programs that ride on the SDLC engineers already use — GitHub, Jira, Okta, AWS — and produce evidence auditors actually accept. SDVOSB-certified, US-based engineers.
Most ISO 27001 programs collapse under their own paperwork
The pattern is predictable. A consultancy hands over a 60-document policy pack written against a generic template, the engineering team never reads it, and six months later the auditor finds change management 'evidence' that's a Confluence page nobody updated since kickoff. Access reviews didn't happen. The risk register lives in a spreadsheet disconnected from the SoA. Management review minutes are backdated. Stage 2 produces a fistful of nonconformities, certification slips two quarters, and the security team burns out maintaining a parallel system that has nothing to do with how software actually ships.
- ▸ Policy templates copy-pasted from another company, with controls that don't match how your team actually deploys to AWS or reviews PRs in GitHub.
- ▸ Statement of Applicability marks controls 'implemented' with no link to evidence, no owner, and no recurring job that produces fresh proof.
- ▸ Risk register built once for the auditor, never updated, never tied to actual treatments or SoA controls — pure theater.
- ▸ Internal audit and management review treated as paperwork rituals instead of the feedback loop ISO 27001 is structured around.
Build the ISMS around how engineering already works — not a parallel paper system
- STEP-01
Scope the ISMS honestly
Define scope by product, environment, and data classification — not by org chart. We map which AWS accounts, GitHub orgs, and SaaS tenants (Okta, Jira, 1Password) are in-scope, and explicitly carve out corp IT if it doesn't touch customer data. Auditors reward precision.
- STEP-02
Build the SoA against Annex A:2022
Walk all 93 controls across the four themes — Organizational, People, Physical, Technological. Mark applicability with a real justification, not 'N/A.' We deliver an SoA tied to specific control owners, evidence sources, and the existing tools producing that evidence (Vanta, Drata, or homegrown).
- STEP-03
Wire controls into the SDLC
Secure development (8.25), change management (8.32), and secure coding (8.28) live in GitHub branch protection, required reviewers, CodeQL, and Jira change tickets. We don't create a second workflow — we instrument the one engineers already use and pipe evidence to the ISMS.
- STEP-04
Run risk assessment and treatment
ISO is risk-driven, unlike SOC 2. We facilitate a risk workshop using a documented methodology (likelihood × impact, with asset-threat-vulnerability tuples), produce a risk register tied to SoA controls, and a treatment plan with owners and dates the auditor can actually trace.
- STEP-05
Prep the Stage 1 and Stage 2 audit
Stage 1 is a documentation review — ISMS scope, policies, SoA, risk register, internal audit, management review. Stage 2 is operating effectiveness over 3+ months of evidence. We run a mock audit, fix gaps, and sit with you during the certification body's fieldwork.
# soa.yaml — Statement of Applicability fragment, ISO 27001:2022 Annex A
# Each control links to owner, evidence source, and SDLC integration point.
controls:
- id: A.5.1
name: Policies for information security
applicable: true
owner: ciso
justification: Required baseline; reviewed annually at management review.
evidence:
- repo: voostack/isms-policies
- doc: confluence/ISMS/InfoSecPolicy-v3.2
- id: A.8.25
name: Secure development life cycle
applicable: true
owner: head-of-engineering
justification: Product is SaaS; SDLC is the primary control surface.
evidence:
- github_branch_protection: main, release/*
- required_checks: [codeql, semgrep, unit-tests, peer-review>=1]
- jira_workflow: CHG board with CAB approval gate
- id: A.8.32
name: Change management
applicable: true
owner: platform-lead
evidence:
- terraform_plan_artifacts: s3://audit-evidence/tf-plans/
- pr_template: .github/pull_request_template.md
- id: A.7.4
name: Physical security monitoring
applicable: false
justification: Fully remote; no VooStack-managed facilities in scope.
An SoA is the spine of your audit — it must tie every applicable control to a named owner and a concrete evidence source the auditor can pull on demand.
Field FAQ.
→ How long does ISO 27001 certification actually take for a software company?
For a 30-150 person SaaS company starting from a reasonable security baseline, expect 4-7 months to certification. Roughly 6-10 weeks to build the ISMS, scope, policies, risk register, and SoA. Then a 3-month operating window so the auditor has evidence of controls running. Then Stage 1 and Stage 2, typically 3-6 weeks apart. Companies starting from zero — no SSO, no formal change management — should plan closer to 9 months.
→ What's the real difference between ISO 27001 and SOC 2?
SOC 2 is a US attestation report against the AICPA Trust Services Criteria, written by a CPA firm, and it's prescriptive about controls. ISO 27001 is an international certification of a management system, issued by an accredited certification body, and it's risk-driven — you justify which controls apply via the SoA. SOC 2 reports are read by US buyers; ISO certificates open doors in EMEA, APAC, and federal. They share roughly 70% control overlap, so doing both is far cheaper than 2x.
→ Do we need to implement all 93 Annex A controls?
No. The 2022 revision consolidated the old 114 controls into 93 across four themes: Organizational (37), People (8), Physical (14), and Technological (34). You apply only the controls relevant to your scope and risks, and you document the rest as not applicable in the SoA with justification. A pure-SaaS company with no offices typically excludes most physical controls. Auditors care that exclusions are reasoned, not that the count is high.
→ Can we use Vanta, Drata, or Secureframe for ISO 27001?
Yes, and we routinely integrate with all three. They're useful for evidence collection — pulling configs from AWS, GitHub, Okta, Jira — and for SoA tracking. They are not a substitute for the management system itself: risk methodology, internal audit, management review, and the actual control design still need real work. Treat the GRC platform as evidence plumbing, not as the ISMS. Auditors notice when a company outsourced thinking to a dashboard.
→ How does the certification body audit cycle work?
After a successful Stage 2 audit, your certification body issues a 3-year certificate. Year 1 and Year 2 you get surveillance audits — shorter, focused on a subset of controls plus any nonconformities. Year 3 is the recertification audit, a full re-examination. Pick an accredited body (UKAS, ANAB, etc.) — non-accredited certificates exist and are not respected by enterprise procurement. Budget roughly $15-40k/year for audit fees depending on scope and headcount.
→ How does ISO 27001 integrate with our existing SDLC?
The technological controls — A.8.25 secure SDLC, A.8.28 secure coding, A.8.29 security testing, A.8.31 separation of environments, A.8.32 change management — should map directly to GitHub branch protection, required reviewers, CodeQL/Semgrep in CI, separate AWS accounts per environment, and your Jira change workflow. We don't add a parallel approval process. We document the workflow you already run and produce evidence artifacts (PR exports, CI logs, Terraform plans) the auditor can sample.
→ What does ISO 27001 mean for federal contracting and SDVOSB work?
ISO 27001 isn't a federal requirement on its own — FedRAMP, CMMC, and NIST 800-171 are the gatekeepers there. But for SDVOSB primes and subs handling CUI or selling commercial SaaS to agencies, ISO 27001 is increasingly listed as a preferred or required qualification, especially for DoD-adjacent and intelligence community work. As a veteran-owned firm, we map ISO controls to NIST 800-53 and 800-171 so a single ISMS supports both commercial enterprise sales and federal pursuits.
→ Who owns the ISMS internally — security, engineering, or compliance?
There must be a named ISMS owner with authority — usually a CISO, head of security, or VP engineering at smaller companies. Compliance staff or fractional CISOs can run day-to-day operations, but ownership cannot live in legal or HR alone because most controls are technical. We recommend a small ISMS steering committee: ISMS owner, head of engineering, head of IT, and a business representative, meeting monthly. Management review happens at least annually with the executive team and is mandatory.
→ What are the most common reasons companies fail Stage 2?
Four patterns: risk register that doesn't tie to the SoA or to real treatments; internal audit done as a checkbox by someone unqualified; management review that never happened or has no minutes; and evidence gaps where a control is documented but not actually operating — usually access reviews, supplier reviews, or change approvals. Auditors sample. If quarterly access reviews are a policy but you only ran one, that's a major nonconformity and certification gets delayed.
Continue recon.
Compliance Engineering
How we wire ISO, SOC 2, and FedRAMP controls into real engineering systems.
REL-02ISMS Build Examples
Walkthroughs of ISO 27001 programs we've taken from kickoff to Stage 2 pass.
REL-03Fixed-Scope Packages
Scoped ISMS build, SoA authoring, and audit prep with defined deliverables and timelines.
REL-04Talk to an Engineer
Skip the discovery call carousel. Talk to someone who has shipped this work.
Ready to scope your ISMS without strangling your engineering org?
Talk to a VooStack operator. We respond within one business day.