Someone just asked you for your ISO 27001 or SOC 2. Maybe it was a prospective enterprise customer. Maybe it was a due diligence questionnaire from an investor. Either way, you are now staring at a requirement you did not budget for, did not plan for, and have no idea how long it will take to satisfy.
Here is the thing nobody tells you in that moment: a significant portion of your compliance evidence already exists. You built it. You just did not label it.
A lot of compliance culture is built around the idea of starting fresh, standing up new systems, buying new tools, and inventing new workflows. That is expensive, slow, and almost always unnecessary for an early-stage team. The faster path is to look at what you have already shipped, the decisions you already made, the tooling you already pay for, and ask a different question: does this count as evidence? More often than not, the answer is yes.
Stop Auditing Your Gaps. Start Auditing What You Already Have.
Before you open a single compliance platform or talk to a single consultant, do one thing. Walk through your existing engineering stack and ask what each tool is already proving about how you operate.
Your Git history is a change management log. Every pull request, every merge, every commit message is a timestamped record of what changed, who approved it, and when it went to production. That is not just version control. In the language of an auditor, that is evidence of a change management process. You did not build it for compliance. It does not matter. It counts.
Your deployment pipeline is a record of continuous activity. If you are running CI/CD, you have automated test results, build logs, and deployment receipts being generated every time you ship. An auditor asking for evidence of regular system testing and controlled deployments can be answered, at least in part, by pointing at your pipeline history. Again: you did not build it for compliance. It still counts.
Your backup routine, even if it is as simple as storing a database dump in a GitHub repository while your data is still small enough to fit, is a documented backup and recovery process. It has a location. It has a frequency. It has access controls. That is the skeleton of a backup policy, and you can write the policy around the practice you already have rather than building the practice from scratch.
This is the creative work of compliance that nobody talks about. Not inventing new work, but recognizing the work you have already done and framing it correctly.
Build Your ISMS Where Your Team Already Works
An Information Security Management System sounds intimidating. In practice, for a startup, it is a collection of documents: policies, procedures, records of decisions, and evidence that those decisions are followed. It does not have to live in an access-managed SharePoint. It does not require a dedicated GRC platform. It can live in GitHub, and there are good reasons to put it there.
GitHub already gives you the two things an ISMS needs most: version control and access control. Every document in your ISMS should be versioned, because auditors want to see that your policies are maintained and updated over time, not written once and forgotten. GitHub tracks that automatically. Every document in your ISMS should have controlled access, because not everyone in your organization should be able to edit your security policies without review. GitHub handles that with repository permissions and branch protection rules.
Write your policies in Markdown. Keep them in a dedicated repository. Use pull requests to make and review any changes to policy documents, the same way you would review a code change. That pull request history becomes your evidence of policy review and approval. When an auditor asks for a PDF, converting a Markdown file to a PDF is trivial. There are several tools that do it in seconds. The format question is not a reason to build in a different system.
The practical setup looks something like this:
- One repository for your ISMS documents, with access restricted to the appropriate people.
- Policies written as Markdown files: information security policy, backup policy, access control policy, incident response procedure, and so on.
- Branch protection rules requiring at least one reviewer to approve changes, creating a lightweight approval workflow.
- A changelog or commit history that shows when each policy was last reviewed and by whom.
- Your CI/CD pipeline, your backup configuration, and your deployment logs living in adjacent repositories that you can point to as supporting evidence.
That is a functional ISMS. It is not perfect. It will not stay this way forever. But it is real, it is auditable, and you built it with tools you were already paying for.
The Git Log Is Already a Compliance Artifact
Let us be specific about what GitHub is proving on your behalf right now, whether you knew it or not.
Access control is demonstrated by who has permissions to which repositories. If you are using GitHub's built-in teams and role management, you have an access control record. Review it, document your intent behind it, and you have an access control policy with supporting evidence in the same place.
Change management is demonstrated by your pull request history. If engineers are not pushing directly to main, if there is a review step before anything merges, that is a controlled change process. Name it. Write a short policy that describes what you already do, and point to the PR history as evidence that you do it.
Backup and recovery is demonstrated by whatever you are already doing to protect your data. If you are storing backups in GitHub while your data footprint is small, document the schedule, document the location, document who has access. You now have a backup policy backed by a real practice.
Continuous monitoring and testing is demonstrated by your CI/CD pipeline. Every green build is evidence that your tests ran. Every failed build that triggered a fix is evidence of a feedback loop. You do not need a separate testing governance document if your pipeline history speaks for itself, though writing a short procedure that describes your pipeline is worth the hour it takes.
None of this replaces the work of a proper audit. There will be gaps. There will be controls you have not implemented yet that a certification body will require. But when that conversation happens, you want to walk in having already identified what you have, not what you lack. Starting from a position of "here is what we already do" is a fundamentally different conversation than starting from zero.
What This Actually Means for You
Startups do things that do not scale. That is not a bug, it is the strategy. Storing your ISMS in GitHub will not be your architecture in five years. Your backup approach will change as your data grows. Your policies will need to mature as your team does.
But right now, the most expensive thing you can do is treat compliance as a greenfield project requiring new tooling, new systems, and new processes built from the ground up. It is almost never true. The honest audit of your existing stack will almost always surface more usable evidence than you expected.
The creative challenge of compliance is not invention. It is recognition. Look at what you have built, name what it is already doing, and document it in the simplest system you have available. For most early-stage teams, that system is already open in a browser tab.
You have a change log. You have access controls. You have deployment records. You have backups. You have a team that reviews code before it ships.
You might already have most of an ISMS. You just have not called it that yet.