ISO 27001 Checklist for SaaS Teams

• Assign an owner for the ISMSName one accountable person — often a founder, CTO, or security lead — who keeps the management system moving. Ownership can be shared in practice, but someone still has to drive it.
• Identify who handles day-to-day security and compliance workList who actually reviews access, handles incidents, talks to vendors, and updates documents. In a small SaaS team this is usually a handful of people wearing several hats.
• Establish how security responsibilities are communicatedDecide how people learn what they own: onboarding, a short RACI, Slack channel, or handbook page. If responsibilities only live in someone’s head, the ISMS will stall.
• Identify existing security processes you can reuseMFA, access reviews, incident notes, vendor lists, and backup tests you already run are ISMS inputs. Start from reality instead of inventing a parallel program.

• Identify internal issues that affect information securityCapture facts about how you actually operate: team size, remote work, cloud-only infrastructure, product architecture, and known operational constraints.
• Identify external issues that affect information securityNote customer expectations, threat landscape relevant to your product, legal/regulatory overlay, and market pressure — without turning this into a generic PESTLE essay.
• Identify relevant interested partiesTypical SaaS parties include customers, employees, contractors, cloud providers, investors, and regulators where applicable. Keep the list useful, not exhaustive for its own sake.
• Capture security requirements that should be addressed through the ISMSPull obligations from customer contracts, security questionnaires, privacy commitments, and any applicable regulation. Decide which of those the ISMS will actually handle.

Smaller teams often benefit from defining a realistic scope instead of automatically including everything the company touches. That is not an invitation to hide systems a customer would reasonably expect to be protected.

• Define organizational boundaries for the ISMSState which legal entity, teams, and functions sit inside the management system. If you exclude a function, be able to explain why.
• Identify products and services includedName the SaaS product(s) customers buy. If a side project, sandbox, or internal tool is out of scope, write that down rather than leaving it implied.
• Identify relevant systems and infrastructureCloud accounts, identity provider, production databases, CI, logging, and other systems that store or process in-scope information.
• Identify locations, important processes, and interfacesRemote-first teams still have locations (home offices, a coworking space, a data region). Document key processes and dependencies on other teams or suppliers.
• Document the ISMS scopeWrite a short, reviewable scope statement. Certification bodies examine the boundary you claim — not the one you meant.

• Establish information security policy directionLeadership should endorse a concise information security policy that states intent and applies to the scoped organization. The document should match how you work.
• Assign ISMS responsibilitiesConfirm who is accountable for the ISMS, who operates controls, and who can approve risk acceptance. Titles can be lightweight; accountability cannot.
• Ensure leadership understands its ISMS responsibilitiesFounders and executives need enough context to resource the work, review performance, and not treat certification as a marketing checkbox.
• Establish ownership and escalation paths for key security processesKnow who to call for access emergencies, incidents, vendor issues, and risk decisions — including after hours if your product requires it.

ISO 27001 is risk-based. You need a repeatable approach your team can explain — not a branded methodology mandated by AuditBird.

• Define a repeatable risk assessment approachWrite down how you identify and evaluate information security risks. Spreadsheet, register, or tool is fine. The method should be usable by the people who own it.
• Define risk criteriaDecide how you judge likelihood, impact, and when a risk needs treatment or acceptance. Criteria should be simple enough that two reviewers would reach a similar conclusion.
• Identify relevant information security risksStart from your scoped systems, data, and processes. Typical SaaS themes include account takeover, supplier outage, leaked secrets, insider access, and backup failure — plus risks unique to your product.
• Assess likelihood and impact, then determine risk levelScore or qualitatively rate each identified risk using your criteria. The output should be a risk level you can compare and prioritize.
• Assign owners to identified information security risksSomeone named — not “engineering” as an abstract noun — should be accountable for each tracked risk.
• Record identified risksKeep a register or equivalent record: description, owner, level, treatment, and review date. If it only exists in a meeting, it is not recorded.
• Review risks periodically and after significant changesRevisit the register on a planned cadence, and when you ship material architecture changes, add a major vendor, or have a serious incident.

The Statement of Applicability connects the organization's risk treatment decisions with control applicability. Not every Annex A control must be implemented. Statement of Applicability — dedicated page coming soon.

• Determine treatment for identified risksFor each material risk, decide whether you will mitigate, transfer, avoid, or accept — with enough rationale that a reviewer can follow the decision.
• Identify controls needed for risk treatmentName the practices that actually reduce the risk: MFA, logging, backups, vendor review, and so on. Controls should follow the risk, not the other way around.
• Compare selected controls against Annex A reference controlsUse Annex A as a reference set to check completeness — not as a mandate to implement all 93 controls. Note gaps, extra controls your risks require, and themes that truly do not apply.
• Document applicable Annex A controls and implementation statusFor controls you include, record that they apply and whether they are implemented, partially implemented, or planned.
• Document justification for inclusions and exclusionsInclusions should tie to risk treatment or other requirements. Exclusions need a clear reason — “we skipped it” is not a justification.
• Prepare and maintain the Statement of ApplicabilityThe SoA is the living map between risk treatment and control applicability. Keep it aligned as systems and risks change.
• Obtain appropriate risk acceptance or approval where applicableResidual risk that leadership is willing to live with should be visible and approved — not hidden in an unread spreadsheet.

Documentation should reflect how the company actually operates. This is not a universal mandatory policy list. Many security policy concepts overlap across frameworks. Browse SOC 2 policy templates and adapt them to your actual ISMS and organization.

• Maintain an information security policyA short, approved policy that sets direction for the ISMS. It should be known to people who need it, not only stored for the audit folder.
• Document supporting processes that match how you operateTypical SaaS topics include access control, risk management, incident handling, supplier security, continuity/recovery, change management, and relevant HR/security procedures. Only write what you will actually run.
• Establish document ownershipEvery controlled ISMS document should have an owner who can update it when the company changes.
• Establish approval and review cadenceDecide who approves documents, how often they are reviewed, and what happens after a material change.
• Control document versions where appropriatePeople should be able to tell which version is current. A dated wiki page with an owner can be enough for a small team if it is actually maintained.

• Define security responsibilities for rolesEngineers, support, and contractors do not need identical duties. Be explicit about access, data handling, and who to notify. Privileged and on-call roles usually need more than generic awareness.
• Run security awareness activitiesPeople who can access production or customer data should understand phishing, secrets handling, and how to report issues. Keep it practical.
• Define onboarding and offboarding security steps, including access removalJoiners get the access they need. Leavers lose it promptly — identity provider, git, cloud, and admin SaaS. Confirm it happened.
• Retain awareness evidence and policy acknowledgement where relevantKeep records that people received guidance or acknowledged policies if that is how you operate. Empty LMS certificates with no matching practice will not help.

The exact control set should follow the organization's risk treatment decisions and applicable requirements. This section does not reproduce all 93 Annex A controls. ISO 27001 controls — dedicated page coming soon.

• Operate identity and access management, including MFA and least privilegeUse a company identity provider where you can. Require MFA for production and admin paths. Default to the minimum access the role needs.
• Perform periodic access reviews and control privileged accessReview who can reach production, customer data, and admin consoles. Privileged and break-glass access should be limited, logged, and known.
• Maintain an asset inventory with ownersKnow the laptops, cloud accounts, SaaS admin panels, and repositories that matter to the ISMS. An unnamed asset is hard to protect.
• Run vulnerability management plus logging and monitoringScan or otherwise track known issues, fix what matters, and keep enough logs to investigate incidents. Depth should match risk, not a vendor demo.
• Apply change management and secure development practices where relevantProduction changes should be reviewable. If you build software, protect secrets, review code, and separate environments in a way that matches how you ship.
• Operate incident management, backups, and continuity practicesKnow how you detect, contain, and learn from incidents. Backups should restore. Continuity, data-handling, and physical/device security should follow your risks — a remote SaaS team still has laptops.

• Maintain a relevant supplier inventory and mark critical vendorsList processors and tools that can affect in-scope information: cloud, identity, email, support, analytics, CI. Flag which ones are important if they fail or are breached.
• Assess information security risk of important suppliersReview what they access, where they host, and whether their security posture is acceptable for that risk. A logo wall is not an assessment.
• Establish security expectations and review contractual commitmentsKnow what the contract, DPA, or security exhibit actually requires — from both sides. Close gaps that matter before they become an incident.
• Periodically review critical suppliers and handle offboardingRevisit important vendors on a cadence. When you stop using a tool, remove access, export or delete data as required, and keep evidence of the review.

• Decide which ISMS and security activities you will monitorPick a small set of recurring activities you can actually watch: access reviews, patching, backup tests, incident follow-up. Optional indicators should change a decision — do not invent vanity KPIs.
• Review whether controls are operating and track unresolved issuesLook at missed reviews, lingering risks, and repeated incidents. The ISMS should tell you if it is drifting — not only if documents exist.
• Keep evidence that recurring activities happenedDates, owners, and outputs of reviews, tests, and follow-ups. A process without a retrievable record is hard to demonstrate.

Internal audit is not the same as the certification audit. AuditBird is not your internal auditor.

• Establish an internal audit programPlan how you will check the ISMS against your own requirements and ISO 27001. This is the organization’s evaluation — not the certification body’s Stage 1 or Stage 2.
• Define audit scope and criteria, and preserve appropriate objectivityState what will be audited and against which criteria. The person checking a process should not simply grade their own homework without a safeguard for impartiality.
• Conduct an internal audit before seeking certification, where appropriateFind gaps while you can still fix them. A first certification attempt without any internal check is a common self-inflicted delay.
• Document findings, assign owners, and track them to resolutionRecord what was found, who will fix it, and when it was verified. Open findings should not vanish into Slack.

• Schedule management review of the ISMSLeadership should review the ISMS at planned intervals. For a startup this can be a focused session with a packet — not a theatrical board offsite.
• Prepare relevant ISMS inputsTypical inputs include security performance, risk status, audit findings, incidents, significant changes, and resource needs. Use what you actually have.
• Review performance, risk, findings, and significant issuesThe meeting should produce decisions, not only a status tour. If something is under-resourced, say so.
• Document decisions and retain evidence of the reviewMinutes or a decision log with actions and owners. Certification bodies look for a real review, not a calendar invite.

• Record identified nonconformities and respondWhen the ISMS or a control is not doing what it should, write it down and contain the issue. Silence is not improvement.
• Investigate causes where appropriate and determine corrective actionsFix the instance, then ask whether the process needs to change. Not every ticket is a root-cause thesis — but repeating failures usually are.
• Assign owners and track corrective actionsEvery action needs a person and a due date. Aging items should surface in monitoring or management review.
• Verify effectiveness where appropriate and retain recordsCheck that the fix held. Keep the record with the original finding so you can show the loop closed.

Prepare for certification assessment. Completing this list does not mean you will “pass the audit.”

• Confirm ISMS scope and review the Statement of ApplicabilityThe boundary and SoA a certification body will examine should match current systems and risk treatment — not last quarter’s draft.
• Review risk records and confirm documented information is controlledRisk assessment, treatment, and policies should be current, owned, and findable. Uncontrolled copies in random folders create avoidable findings.
• Organize evidence and verify internal audit and management reviewPut samples where the team can retrieve them. Confirm an internal audit and a management review actually occurred and that actions were followed.
• Review unresolved corrective actionsKnow which findings are still open, why, and what you will tell the certification body. Hidden issues tend to surface in Stage 2.
• Select an appropriate certification body and prepare for Stage 1 and Stage 2Certification is issued by an independent certification body, not by AuditBird. Stage 1 typically reviews documentation and readiness; Stage 2 examines whether the ISMS operates. Prepare for assessment — do not treat either stage as a score you can game.