The first 90 days of a GRC programme: what to build, defer and kill
The failure of most GRC programmes isn't an absence of effort; it's a misallocation of it. New security leaders often drown in policy templates or get trapped in 'spreadsheet hell' before they have identified a single meaningful risk to the business. This guide outlines a ruthless 90-day execution plan to build a credible Governance, Risk, and Compliance function that moves as fast as your engineering team.
Michael McCarroll— Founder · 20+ yrs GRC, ISO 27001 lead implementer 16 min read Updated June 2026
Days 1-30: The Discovery Phase and Asset Mapping
Days 1 through 30 are about discovery and scoping. You cannot protect what you do not know exists, yet many founders try to skip straight to ISO 27001 certification without defining the boundaries of their environment. Start by identifying your 'Crown Jewels'—the data and systems that, if compromised, would end the business. This isn't just about servers; it is about your customer database, your proprietary source code, and your billing systems.
Kill the 'Policy-First' mentality. Writing a 50-page Information Security Policy in Week 2 is a mistake because no one will read it and it won't reflect reality. Instead, focus on the Asset Inventory. If you can't tell me who has access to your production AWS environment or which SaaS tools are processing PII, your policies are just fiction. Use the first month to interview department heads and map the data flow.
By the end of Day 30, you should have a draft Scope Statement. Be precise here: if your corporate office is just a WeWork, exclude the physical infrastructure and focus on the logical assets and remote workforce. This clarity prevents 'scope creep' which is the primary reason certification projects blow past their budgets and timelines.
Definition of the ISMS Scope (Clause 4.3) - what’s in and what’s out.
Asset Inventory - starting with identity providers and cloud infrastructure.
Initial Risk Methodology - keep it simple, 3x3 or 5x5.
A 'Gap Analysis' against Annex A - used as a roadmap, not a tick-box.
Days 31-60: Risk Assessment and Control Architecture
Days 31 to 60 are where you build the engine. This is the risk assessment phase, specifically satisfying ISO 27001 Clause 6.1.2. Don't fall into the trap of identifying 200 minor risks. Focus on the 'Vital Few'—typically 15 to 25 risks that actually matter. These usually include things like 'unauthorised access to production DB' or 'single point of failure in key personnel.' Give each a score and, more importantly, an owner.
Once the risks are identified, you must decide what to do with them: Treat, Tolerate, Transfer, or Terminate. This shouldn't be a solo exercise for the Head of Security. You need the CTO and CEO to agree on the 'Risk Appetite.' If the board is fine with the risk of a 4-hour outage once a year but won't tolerate a 1-minute data breach, that dictates exactly where you spend your limited budget.
Defer the 'nice-to-have' controls. If you are a 50-person startup, you probably don't need a formal SOC 24/7 or a hardware security module (HSM) for every secret. In this phase, you are building the Minimum Viable Compliance (MVC). This means implementing MFA across the board, establishing a basic joiners/movers/leavers process, and ensuring your backups are actually being tested.
Risk Register - populated with the top 15-20 existential threats.
Control Selection - specifically those addressing identified risks.
Stakeholder Buy-in - formal sign-off on the risk treatment plan.
Access Control Baseline - cleaning up 'zombie' accounts.
Days 61-90: Operationalise and Evidence
The final 30 days are about operationalising and proving performance. This is where you conduct your first Management Review. This isn't just a status update; it's a formal requirement of Clause 9.3. You present your risk landscape, your control effectiveness, and your need for resources to the leadership team. If you haven't had this meeting by Day 90, you don't have a GRC programme—you have a hobby.
Kill the idea of manual evidence collection. If you are still taking screenshots of your AWS IAM console to prove you have MFA enabled, you have already lost. Use this period to set up automated monitoring. The goal is to have 'continuous compliance' so that when a potential enterprise customer sends you a 300-question security questionnaire, you can answer it in minutes using verified data rather than hunting through folders.
Conduct a Tabletop Exercise for Incident Response. Take your leadership team through a simulated ransomware attack or a data leak. This 2-hour investment does more for your security culture than any 'Security Awareness' slide deck ever will. It exposes the gaps in your communication channels and decision-making authority that no spreadsheet can capture. High-growth firms succeed here because they prioritise resilience over perfection.
Internal Audit - a dry run to find the holes.
Management Review (Clause 9.3) - the formal governance meeting.
Incident Response Tabletop - testing your muscles.
Evidence Repository - moving from manual to automated.
What to Defer and What to Kill: The Ruthless Prioritisation
Knowing what to defer is as important as knowing what to build. I often see firms trying to implement a full Business Continuity Plan (BCP) with hot-site failover in the first three months. Unless you are a high-frequency trading firm, defer the complex DR testing. Document the recovery objectives (RTO/RPO) and ensure you have backups, but leave the multi-region failover drills for Day 180+.
Similarly, defer the exhaustive Vendor Risk Management (VRM) programme. You likely use 100+ SaaS tools. Attempting to audit all of them in 90 days will paralyse the business. Instead, tier your vendors and only perform deep-dive assessments on the 'Tier 1' providers—those who touch your customer data. The rest can be handled with a simple SOC2 report check for now.
You must also kill 'Shadow GRC'—the habit of different departments using their own trackers and risk lists. Consolidate everything into a single 'Source of Truth.' If it's not in the central GRC platform, it doesn't exist for the purpose of the audit. This prevents the nightmare scenario of an auditor finding a risk list in the Engineering Jira that contradicts the official Risk Register in the Security folder.
Deep-dive BCP/DR testing – start with a dry run, save the real failover for later.
Extensive vendor risk assessments – focus on the top 5 vendors first.
Customised advanced training – get the basics out first.
Tooling for ISO 27001:2022 transition – stay on the current version until your foundation is solid.
Day 90 and Beyond: Turning Compliance into a Growth Engine
By Day 90, your GRC programme should be a tool for the Sales team. Compliance is not a cost centre; it is a revenue enabler. When your Sales Rep can hand over a 'Trust Pack'—containing a summary of your ISO 27001 scope, a letter of intent from an auditor, and a high-level security whitepaper—you reduce the sales cycle by weeks. This is how you prove the value of your first 90 days to the CEO.
The transition from 'Project' to 'Business as Usual' (BAU) is the final step. GRC is not a one-time event; it's a cycle of Plan-Do-Check-Act. Your risk register should be a living document, updated as the product changes. If you’ve built it correctly, the 90-day mark isn't the finish line—it's the point where the flywheel starts to spin on its own, providing the trust signals your customers demand.
Sales Enablement - security as a revenue driver.
Feedback Loops - getting info from the front lines.
External Audit Readiness - the final polish.
Ready to turn compliance into a competitive advantage?
Transform your risk register from a static spreadsheet into a growth engine. ISO-STANDARD.app provides the scaffolding you need to execute this 90-day plan, helping you automate evidence collection and prove your security posture to sophisticated buyers.
ISO-STANDARD.app ships a ready-to-adopt GRC workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.
Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.
Frequently asked questions
Should I hire an auditor in the first 30 days?
Not immediately. In the first 90 days, your focus should be on the 'Scope' and 'Risk Assessment' clauses (4.3 and 6.1). You need a working system before you audit it. Attempting an internal audit before you have at least two months of operating history is a waste of resources and will result in a 'clean' report that misses systemic failures.
How complex should my risk methodology be?
Avoid deep-dive quantitative risk modeling (like FAIR) initially unless you have a dedicated data science team. For most firms, a qualitative 3x3 or 5x5 matrix—measuring Likelihood vs. Impact—is sufficient to drive board-level decisions. The goal is prioritisation, not mathematical perfection.
What is the biggest mistake in early-stage GRC?
The ‘Security Committee’ is often a ghost ship. Instead, embed risk discussions into existing Product or Engineering leadership meetings. If you create a new, separate meeting, busy stakeholders will eventually stop attending or send junior proxies who cannot make decisions.
Can I use AI to accelerate the first 90 days?
Yes, but with caveats. Use it to draft the first version of policies or to map controls across frameworks. Do not use it to perform risk assessments; AI lacks the context of your specific business logic and 'crown jewels,' which often leads to generic and useless risk registries.
Action checklist PDF
Mirrors this guide with owners, artefacts & a 30/60/90-day plan.
