Tech Audit Report Template

	A	B	C	D	E	F	G	H
1	Disclaimer! Before filling the template out create a copy and save it to your Google Drive.
2
3	Criterion	Risks	Complexity	Level	Level 0	Level 1	Level 2	Level 3
4	Hiring

5	Programming languages	It's hard to find developers for a project written in an inactual language.			A project is written in a completely obsolete programming language, for example, Pascal	A project is developed in deprecated or marginal languages, such as CoffeeScript or Haskell	A project is developed on actual versions of popular programming languages, for example, Python 3 or TypeScript 4.x.	Same as level 2, but there are just 1 or 2 languages used
6	Frameworks & libraries	Hiring developers for a project where old or little-known frameworks and libraries are used can also be a problem.			No frameworks or a self-written framework is used on the project.	A project uses deprecated frameworks, such as Ember or jQuery.	A project uses a deprecated version of a popular framework, for example, an old version of Django.	A project uses popular and up-to-date frameworks and libraries.
7	Onboarding
8	Documentation	Without adequately written and sufficient documentation, it's much more complicated for developers to understand both the business and tech sides of a project.			There is no documentation on the project.	There is some documentation, but it's not helpful or outdated.	Documentation is informative and helpful, but some topics, such as infrastructure or API, are not covered.	Documentation is complete and up-to-date. Data is visualized where necessary.
9	Designs	When design or its part is missing, developers may need much more time to understand a project.			There are no designs on the project.	Designs are partial or outdated.	Designs are complete and up-to-date.	Designs are complete, up-to-date, and have designer's comments.
10	Test specification	Without a test specification, the project can't pass the testing stage and consequently be published.			There is no test specification on the project.	Confluence was used once, but no more.	Test cases are in confluence and up-to-date.	End-to-end tests on the project are written based on a BDD approach.
11	Development
12	Local development	If there is no local development environment, creating and deploying new features becomes extremely difficult.			There is no local development on the project.	There were attempts to make to start a project locally, but at the moment, it's impossible.	It's possible to run the project locally, but an advanced setup is required.	The whole project can be set up by running a single command with no prerequisites.
13	Testing environment	Without a testing environment, it's impossible to test features and ensure the end-quality of the product before rolling them to production.			Production is a testing environment.	There is a testing environment but it is outdated.	There is an easy-to-deploy testing environment on the project.	Each PR has a stand with its own dataset. Optionally, it can be prepopulated with some data.
14	Code checks	Automated code checks speed up development and help detect non-obvious mistakes.			The code is not checked at all.	There are linters, but they fail or are ignored by developers.	Linters are set up, work on CI, and run on every commit automatically.	Same as level 2, and an autoformatter is used to make development faster.
15	Architecture	Unsuitable project architecture can slow down the project performance and makes refactoring and new feature development more difficult.			Unsuitable architecture or tech stack is selected.	Over-complicated architecture, nonoptimal stack, or unsuitable services and tools are used on a project.	Suitable architecture and tech stack are used on a project but there are some minor issues.	Suitable architecture and tech stack are used on a project anf there are no issues.
16	Data architecture	Bad data architecture slows development, causes constant errors and leads to money and data loss.			A wrong type of database is used (No-SQL instead of SQL), or a project has a wrong data structure.	A suitable database is used, but it requires huge refactoring.	Same as level 3 but some minor changes or setup are required.	A project uses a popular and suitable database. Normalized data structure is used in SQL DB, de-normalized - in NO-SQL. Best practices are applied.
17	Code organization	Bad code organisation slows development and causes errors.			All code is kept in one file.	Some architecture is used but without understanding.	Code is organized.	Well-grained modules and a "screaming" architecture: just by looking at a project at a glance, developers can get its core idea.
18	Task management	Without an organized task management system, project management is impossible.			Phone calls or messages from CEO at 3am	Google Docs	Jira or Osana is used, but tickets often contain no description.	Jira or Osana is used, tickets are well-defined and sprints or a Kanban board are set up.
19	Designs	Without a good design, developers can't deliver features fast.			There are no designs on the project.	Designs are partial or outdated.	Complete and up-to-date designs in Figma but files are not well-organized.	Complete, well-organized and up-to-date designs with reusable components in Figma.
20	Repository organisation	Bad VCS organization leads to slow debugging and development			No version control is used.	Code in the VCS is kept chaotically.	Commits and feature branches are set up and attached to tickets	Intergration with GitHub, GitLab or BitBucket is used.
21	Deployment	If deployment is not tuned and automated, it leads to missing deadlines.			Manual deployment on the project.	There are scripts, but they are broken or do not work correctly.	Deployment is automated, but human involvement is still required.	A new project version can be deployed just by pressing a button in the CI/CD system.
22	Comments	Without comments, developers might take a very long time to understand the codebase.			No comments on a project.	There are comments, but they simply rephrase the actual code.	There are helpful comments on some non-obvious parts of the code.	Every module has sufficient documentation or self-documented code.
23	Tests	Lack of tests slow development and makes a project unstable because problems may occur at unintended places.			No tests on a project.	There are unit or integration tests, but most fail to pass or are ignored.	There are unit or integration tests, but code coverage is <70%.	There are end-to-end tests for all cases.
24	Reliability
25	Hardware	Usage of weird solutions (instead of popular AWS, for example) can cause significant problems with development and maintenance.			A project runs only locally on a single device.	A project runs on the dedicated server deployed with the usage of Ansible.	A project runs on an EC2 instance or likewise with the usage of a Docker container.	A project runs on a distributed cloud cluster, such as Kubernetes within AWS or Fargate.
26	Monitorings	Unless monitorings are set up, developers can't track any project metrics.			No monitorings on a project.	Monitorings exist but they work on their own.	Key metrics are displayed on the monitorings.	Key metrics, filtering and slicing are set up to detect "hot points".
27	Performance	A solution with low performance requires a lot of refactoring or architecture/infrastructure changes.			The main page loads in 20 seconds.	Most requests take seconds to finish.	A solution works fast, but some specific requests may run too long.	The verage response time is <50ms.
28	Backups	If there are no backups, data can be lost permanently.			No backups on a project.	There are manual backups that don't work.	There are regular backups with manual restoring only.	There are regular backups and instruments to restore backups.
29	Alerts	If there are no alerts on a project, you will know that your service is down from your customers.			No alerts on a project.	All alerts are messages to the Slack channels.	There are SMS or emails alerts and they are prioritized.	In case of an emergency, a robot will call the on-duty staff.
30	Logging	If there are no logs, it's impossible to trace the problems — and, therefore, fix them.			No logging on a project.	Docker logs or OS log files are used.	CloudWatch or a likewise solution is used.	ELK stack or a similar solution is used along with advanced search and filters.
31	Error tracking	If there is no error tracking on a project, it is impossible to learn about potential code errors.			No error tracking on a project.	Log files are parsed to find errors.	Sentry.io is used	Sentry.io or a similar solution is used along with request tracing and performance metrics.
32	Security
33	Prevents SQL injections	The whole database can be stolen or corrupted via SQL injections.			Raw SQL requests are made.	Raw SQL requests use a wrong escaping strategy.	Raw SQL requests use escaping.	Well-known ORM is used; there is no raw SQL.
34	Uses CSRF-tokens, CORS, CSP	There is a high risk of user data being stolen			There is no protection on a project at all.	Team tried to setup CORS or CSRF, but it doesn't work correctly	Basic CORS or CSRF protection is used	CORS, CSRF and CSP are set up
35	Prevents XSS	There is a high risk of user data being stolen			User input is stored as is; no escaping is used on UI.	User input is manually escaped on UI.	User input is escaped on UI by a framework or template engine.	User input is escaped on UI and filtered on the server side.
36	Infrastructure credentials security	One of the biggest vulnerabilities is when any developers with access to the code base can use passwords or other confidential information for their purposes, damaging or deleting data. Also, it should be considered: when an employee leaves, he may still use this information.			Credentials are plainly stored in the repository.	Credentials are not stored right in the repository, but stored in some unencrypted document instead.	AWS secret manager or a similar tool is used on a project.	Environment variables, AWS Secret Manager, Vault, or similar tools are used. Only authorized persons have access to production databases, servers, etc.
37	User credentials encryption	In case of data breach, the user password must be deduced and used to access user's email and other services.			User credentials are not encrypted.	Credentials are encrypted using unsuitable algorithm, for example, MD5.	Credentials are encrypted.	Credentials are encrypted using salt or third-party authorization service is used.
38	DDoS protection is set up	If there is no firewall on a project, it may increase the risks of attacks, downtime, application loading time, and chances that bots will scrape data.			No firewalls on a project.	Primitive or unsuitable tools are used for protection.	Cloudflare is used.	Cloudflare is used with advanced security settings (scraping bots, attacks, etc.).
39	Total
40	Summary		0 / 0		The project is a total failure, impossible to maintain or develop.	The team planned to follow best practices, but clearly failed.	The project is absolutely OK, but there is space for improvement.	The project is brilliant in almost every aspect.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100