Code Audit Checklist: What to Check and How to Report It

A code audit checks a whole codebase against a fixed list: security, architecture, dependencies, tests, documentation, performance and operations. A code review checks one change before it merges. This page gives you the checklist for the audit, a shorter one for reviews, the Swiss data protection checks that often get missed, and a format for writing up what you find.

It is written for founders, CTOs and owners who are about to inherit code, buy a product, raise money or sign off on a launch. You do not have to be an engineer to follow it. You do need to be able to ask the right questions and recognize a straight answer.

TL;DR

• An audit reviews the whole codebase; a review checks a diff. OWASP separates the two, and your checklist should too.
• Work in priority order: can it run from scratch, then security, architecture, dependencies, tests, documentation and performance.
• Let tools handle formatting and known vulnerabilities. Spend human time on business logic, authorization and data flows, which scanners miss.
• In Switzerland, add the data protection checks: a DPIA where risk is high, breach documentation and an accurate privacy statement.
• Every finding needs a location, impact, evidence, severity and a fix. Then verify the fixes.

Code audit or code review: which one do you need?

People search for “code review checklist” and “code audit checklist” as if they were the same thing. They are not, and mixing them wastes time.

A code review looks at a proposed change, usually a pull request. It happens many times a week, takes minutes to an hour, and its goal is to stop a bad change from entering the codebase. OWASP calls this a diff-based review.

A code audit looks at the entire codebase at a point in time. It happens once before a launch, a funding round, an acquisition or a handover, or yearly for systems that matter. OWASP describes the baseline review of a whole codebase as a separate activity from reviewing changes. It takes days or weeks and ends in a written report with a decision.

The practical rule: reviews keep quality from slipping, audits tell you where you actually stand. If nobody has ever audited your code, start there. If you audit every year but merge unreviewed code in between, fix that first.

Before you start: scope and preparation

Most bad audits fail before anyone reads a line. Settle these first.

1. Define the question. “Is this safe to launch?”, “Can a new team maintain it?” and “What is it worth?” lead to different audits. Write the question at the top of the report.
2. Fix the scope. List the repositories, services, infrastructure definitions and third-party integrations in and out of scope. A Swiss university course on code review stresses keeping the amount under review manageable. The same applies to an audit: a narrow scope done well beats a broad scope done shallowly.
3. Prepare the material. Code should be formatted and documented enough to read, and the sections needing in-depth review should be marked. For an audit, that means the risky parts: login, payments, file uploads, admin tools and anything that touches personal data.
4. Gather context. OWASP’s guidance asks reviewers to understand the business requirements, threat model and critical assets before judging code. Ask for architecture diagrams, a list of environments and a list of who has access to what.
5. Agree who reads the result. A founder needs a one-page verdict. An engineer needs file paths. Plan for both.

The code audit checklist

The order below is deliberate. If the first item fails, the rest matters less.

1. Can it run from a clean checkout?

Clone the repository on a machine that has never seen it and follow the README. Count how many undocumented steps you need.

• Does the project build and start from the documentation alone?
• Are environment variables listed, with safe example values?
• Can you run the tests with one command?
• Is the deployment process written down, or does it live in one person’s head?

If only one person can build and deploy the product, that is your first finding, whatever the code looks like.

2. Secrets and access

• Search the current code and the commit history for API keys, passwords, tokens and private keys. A key deleted last month is still in the history.
• Confirm secrets come from a secret store or environment configuration, not from files in the repository.
• Check who holds repository, cloud, domain and DNS access. Ex-contractors should not.
• Rotate anything that was ever exposed. Removing it from the code is not enough.

3. Authentication and authorization

These are two different checks, and the second is where tools help least.

• Authentication: how are passwords stored, how do sessions expire, is multi-factor login available, how does password reset work?
• Authorization: when a logged-in user requests another user’s record by changing an ID in the URL, what happens? Is the permission check on the server for every endpoint, including admin and internal ones?
• Are session cookies flagged secure and are sessions invalidated on logout?

OWASP’s guidance lists authentication, authorization, input validation, cryptography, error handling, configuration and deployment among the areas a secure review must cover.

4. Input, output and data handling

• Are database queries parameterized, so user input never becomes part of a query string?
• Is output encoded before it is rendered, to prevent cross-site scripting?
• Are file uploads restricted by type and size, and stored outside the web root?
• Is sensitive data encrypted in transit and at rest, using standard libraries and not home-made cryptography?
• Do error messages and logs avoid leaking stack traces, tokens or personal data?

A short secure-review list like this one, with secrets, parameterized queries, output encoding and session handling, is a reasonable minimum. Anchor deeper work to a standard such as the OWASP ASVS, as the OWASP DevSecOps guideline suggests.

5. Dependencies and supply chain

• Is there a lockfile, and is it committed?
• Run the package manager’s audit command and a software composition analysis scan. How many known vulnerabilities are there, and how many are in code that actually runs in production?
• Are any packages abandoned, unmaintained for years, or pinned to a very old major version?
• Do all dependencies exist and come from the registry you expect? This matters most in code produced with AI assistants, which can suggest package names that are wrong.
• Are licenses compatible with how you sell the product?

6. Architecture and boundaries

• Can you draw the system on one page: components, data stores, third-party services, and the lines where data crosses trust boundaries?
• Is business logic in one place, or copied across the frontend, backend and scripts?
• Is there a single point of failure, such as one server, one database without backups or one person?
• Are modules separated enough that you could replace one (the payment provider, the CRM) without rewriting everything?
• Does the design match the requirements, or has it drifted into something the original team would not recognize?

This is the section where a senior reviewer earns the fee. A linter cannot tell you the data model will not survive your next five customers.

7. Tests

• Does the suite cover new behavior and edge cases, not only the happy path?
• Do tests check outcomes rather than implementation details, so refactoring does not break them?
• Do tests cover error handling?
• Is there a continuous integration pipeline that runs them on every change, and does the team actually stop when it fails?
• Are the riskiest flows (checkout, permissions, data export) tested end to end?

Coverage percentages are a weak signal. A system with 80 percent coverage and no tests for permissions is less safe than one with 50 percent that tests the right things.

8. Code quality and maintainability

• Can a new developer understand a typical file in a few minutes?
• Are there huge files or functions that everyone is afraid to touch?
• Is there dead code, commented-out blocks or duplicated logic?
• Is there consistent formatting enforced by a tool, not by opinion?

Keep this section proportionate. Style is the least important finding in an audit, and treating it as equal to an authorization hole hides the real risks.

9. Performance and scalability

• Where are the slow database queries? Look for queries inside loops and missing indexes.
• Is anything cached that should be, and is anything cached that should not be?
• What happens under ten times today’s load? Has anyone tried?
• Are background jobs retried safely, or can a failure send an email twice or charge a card twice?

10. Configuration, deployment and monitoring

• Are development, staging and production separated, with different credentials?
• Is infrastructure defined as code, so a lost server can be rebuilt?
• Are backups taken, and has a restore ever been tested?
• Is there monitoring, alerting and log retention, and does someone get woken up when it breaks?
• Is there a security monitoring plan for detecting suspicious behavior?

11. Documentation and handover

• Is there a README, an architecture overview and a list of integrations?
• Are decisions recorded somewhere, even briefly?
• Could a competent stranger take over in two weeks? If not, you are dependent on the people who wrote it.

Swiss checks: data protection and sector rules

Generic checklists come from the US and EU and rarely mention Switzerland. If your software handles personal data of people in Switzerland, add these.

Data protection impact assessment (DPIA). Under the Swiss Federal Act on Data Protection (FADP), a controller must carry out a DPIA when planned processing is likely to pose a high risk to the personality or fundamental rights of the people concerned. The Federal Data Protection and Information Commissioner’s factsheet on the DPIA says it should describe the processing, evaluate the risks and set out protective measures. It also calls the DPIA a proactive working tool for digital projects, not a paperwork exercise. In an audit, ask whether one exists for features like profiling, health data or large-scale tracking, and whether the code matches what it says.

Breach documentation. The Data Protection Ordinance requires controllers to document breaches, and a report to the Commissioner must state the form of the breach, its consequences and the measures taken or planned. Check that logging is good enough to reconstruct what happened. If your logs cannot tell you which records were accessed, you cannot write that report.

Privacy statement versus reality. The Commissioner’s page on privacy statements on the internet tells controllers to analyze their data processing first and then answer what is collected, why, where and how long it is stored, and whether it goes abroad. In the audit, trace each analytics script, form and third-party SDK and compare it with the published statement. Cloud regions and international transfers are the usual gaps.

Sector rules. Switzerland has a technologically neutral legal framework rather than one universal secure-development certification, as this Swiss law firm overview of cybersecurity describes. So the checklist has to fit the product and the data. The same overview notes that eHealth Suisse expects medical software to define security at design, run a risk analysis and document verification, validation, updates and the protection of sensitive data. Financial, health and public sector clients usually add contractual requirements on top, so ask for them before the audit starts.

If your site is public-facing and you want a second set of eyes on its exposure, a few website security checks can complement the code-level review.

Automation versus human judgment

A good audit uses both, and knows which to use where.

Tools are good at repeatable work: formatting, static analysis, known-vulnerable dependencies, secrets patterns. Sourcegraph’s review guidance makes the point for reviews too: automate what repeats so people can concentrate on design and logic.

People are needed for the rest. OWASP states that automated SAST and DAST tools complement, not replace, human review, because business logic, data-flow context and complex security controls need a person who understands the product. A scanner will not notice that a discount code can be applied unlimited times, or that an invoice endpoint returns another customer’s invoice.

Use tools first to get a map, then read the code where the map says it matters.

The shorter checklist for code reviews

For day-to-day pull requests, keep the list to a single screen. Long checklists get ignored.

Check	Question to ask
Requirements	Does the change do what the ticket asked, and nothing else?
Correctness	Are edge cases and failure paths handled?
Readability	Would someone new understand it without the author present?
Tests	Are new behavior and edge cases covered, with assertions on outcomes?
Security	Any new input, permission, secret or query that needs a closer look?
Architecture	Does it fit the existing design, and what else does it affect?
Operations	Does it need a config change, migration or monitoring?

Two habits make this work, both described in the Sourcegraph guide. Prioritize blocking issues first, and label style comments as nits so the author knows what must change. The ETH course material adds that authors and reviewers should each have a checklist, discussion should stay on technical defects and the team should record defects and follow up to confirm they were fixed.

One caveat: treat any checklist as a memory aid, not a replacement for judgment, and update it when the team learns something. If a bug slipped through, add the question that would have caught it.

How to write up the findings

An audit is only worth what the report lets you do. Use the same structure for every finding, following OWASP’s guidance on reporting:

1. Component and location: the service, file and line.
2. Issue: what is wrong, in one or two sentences.
3. Impact: what could happen, in business terms.
4. Evidence: reproduction steps, a request, a screenshot or a code excerpt.
5. Severity: critical, high, medium or low, with a stated rule for each.
6. Remediation: what to change, specific enough to estimate.

Then add a summary page: the verdict on the question you set at the start, the top five risks, and a rough order of work. Group findings into “fix before launch”, “fix this quarter” and “accept and monitor”.

Finally, follow up. Record the findings in a report and check afterward that each defect was fixed, as the ETH material puts it. Re-test critical and high items yourself instead of taking a status update on trust.

A worked example: pre-fundraise audit

Suppose you are a founder with a working product built by two freelancers, and an investor asks for technical due diligence. You have a week.

• Day 1: clean checkout, secrets search and access list. If either fails, fix it before anyone else looks.
• Day 2: authorization on every endpoint that returns user data. Test with two accounts.
• Day 3: dependency scan, lockfile and licenses.
• Day 4: architecture sketch, backup and restore test, deployment walkthrough.
• Day 5: tests, documentation, and the data protection questions: does your privacy statement match your trackers?
• Day 6 and 7: write the report, sort findings into three groups and fix the cheap critical ones.

You will not find everything. You will find the things an investor’s engineer finds in the first hour, and that is what you need.

When to bring in someone else

Do the first pass yourself if you can read code. Bring in an outside reviewer when you are not independent (you wrote it or you pay the people who did), when the stakes are high (a funding round, an acquisition, regulated data), or when no one on the team has seniority in the stack.

At Ampersand, we run audits and technical due diligence as part of our consulting work, and the people who do the audit are the same senior engineers who would fix what it finds. We are a small Zurich studio, and our clients include UBS and the City of Lugano. If you want to see how we work before you decide, our studio portfolio shows recent projects, and the pricing page lists the engagement formats. Our Guidance plan is listed at CHF 799 per month and Run & monitor, our ongoing support plan, at CHF 750 per month. Audits and other engagements are scoped individually, so the page does not show a price for them. If you would rather learn the process and run audits yourself, you can ask us to set that up as coaching.

FAQ

What is the difference between a code audit and a code review?

A code review checks a single change, such as a pull request, before it is merged. A code audit examines the whole codebase at one point in time, usually before a launch, sale or handover. OWASP treats whole-codebase review and diff-based review as two separate activities.

How often should we audit our code?

Audit before major events: a launch, a funding round, an acquisition, a change of development team. For systems that hold sensitive data, a yearly audit is a reasonable rhythm. Review every change in between, so the audit finds drift and not a pile of surprises.

Can automated tools replace a manual code audit?

No. Scanners handle formatting, known vulnerabilities and common patterns well. OWASP’s guidance says human review is still needed for business logic, context-specific authorization and architecture, which tools tend to miss. Use tools to guide where people look.

Do Swiss companies need to audit code for data protection?

The FADP does not require a code audit as such. It does require a DPIA when processing is likely to pose a high risk, documentation of breaches and an accurate privacy statement. A code audit is a practical way to check that the software really does what those documents claim.

Sources

• Secure Code Review, OWASP Cheat Sheet Series
• Secure Code Review, OWASP DevSecOps Guideline
• Code Review, ETH Zurich software architecture course
• The Code Review Checklist for Engineering Teams, Sourcegraph
• Factsheet on the data protection impact assessment, FDPIC
• Ordinance on Data Protection (SR 235.11), Fedlex
• Privacy statements on the internet, FDPIC
• Cybersecurity in Switzerland, Walder Wyss