This dev, test and prod environment checklist has 11 checks, and you mark each one three times. One mark goes to dev, one to test and one to production. The totals matter. Still, the rows where the three marks disagree say more. Each of them points at a stage that has fallen out of step with the others.
Last reviewed 2026-11-08 by Manish Sharma.
DevOps teams can also treat it as a DevOps environment checklist for the stages alone. It is not a maturity review of the whole practice. For a one-line grounding in the term, see what DevOps means.
The reader we had in mind leads IT or engineering for a mid-size Indian or GCC company, with all three stages already running. Score before a go-live, an audit or a move to a new host, when there is still time to act on the rows.
Three Marks per Check in This Environment Checklist
Each check takes a 2, a 1 or a 0 in every stage, and the mark depends on a record someone can pull up today.
- 2: the record carries a date inside the last 90 days (the window) and covers the whole stage.
- 1: a record exists, but it covers only part of the stage or dates from before the window.
- 0: nobody can find a record, or the only support is a spoken assurance.
N/A is for a check that makes no sense in a given stage. Write the reason beside it, then total that stage over the remaining checks instead of over 22.
The stage owner writes down the marks, and an owner from a different stage then checks each record behind them. Any record this second reader fails to find costs the mark, which becomes 0.
Take one line of check 1 as a trial: the database version listed for each stage. Dev and test each hold an inventory export from three weeks ago that names the version, and each earns 2. However, the production list is five months old and predates an upgrade, which earns it a 1. The row reads 2, 2, 1. The unequal mark sends you to production first, even if you expected production to be in best order.
No total counts as a pass. Signisys offers the 2/1/0 scale, the N/A rule and the 90-day window as a starting point. Your audit cycle may call for different ones.
What Exists in Each Stage and What It Should Be
Checks 1 and 2 record what each stage runs today and what it should run. The other nine checks take them as their reference point.
| No. | Check | Record to open | Scores 2 in a stage when | Who checks it |
|---|---|---|---|---|
| 1 | Inventory per stage | A dated list of the stage’s components, versions and outside services, such as a payment gateway. | The list matches what runs today, and its date falls inside the window. | The owner of another stage compares three items on the list with the running system. |
| 2 | Written baseline, with intended differences | The stage’s baseline document, as well as a list of the differences between stages that exist on purpose. | The baseline names versions and settings, and the list also says what each difference means for testing. | A tester reads the list, then says which results test does not cover. |
NIST SP 800-128, the Guide for Security-Focused Configuration Management, notes that one baseline can represent each of the development, test and production stages. Check 2 asks for that baseline in writing, stage by stage.
The differences list carries as much weight as the baseline. Say, for example, test has half of production’s memory, or a mock stands in for a payment gateway. That is fine once someone writes it down, because testers then know which results to read with care. Here the environment checklist caps check 2 at 1 when the differences list is empty. The exception is a stage that really does match production in every respect.
Environment Checklist: Are All Stages Built From One Definition?
Checks 3, 4 and 5 ask whether the stages come from one source and whether every change leaves a trace. The build method does not affect the mark. Scripts, templates and machine images, for instance, can each score 2. Picking among those methods is a separate decision, covered in a side-by-side look at six kinds of approach.
| No. | Check | Record to open | Scores 2 in a stage when | Who checks it |
|---|---|---|---|---|
| 3 | Configuration in version control | The repository that holds the stage’s configuration, including its history. | Every setting for the stage sits in the repository, and stage files differ only in values such as hostnames and sizes. | A developer from another team finds one setting in the repository, then finds it on the running system. |
| 4 | Built from one definition | The record of the stage’s last build or update, with the definition version it used. | The shared definition built the stage with the same OS, runtime and middleware versions as the others, unless check 2 lists the difference. | The owner of another stage matches that definition version against their own build record. |
| 5 | Change record, emergency fixes included | The stage’s change log for the window, set beside the system’s own change history. | Every change on the system appears in the log, including fixes made straight on a server during an incident. | Someone outside the team picks two changes from the system history and finds each one in the log. |
Check 5 is one where production can lose marks. Picture a fix applied by hand at 2 a.m. during an outage. It may solve the problem that night. However, unless it reaches the change log and then the definition, the next rebuild takes it away again.
Who Can Reach Each Stage, and What Data It Holds
Checks 6 and 7 cover credentials and data. Here a gap between stages can do harm well beyond a failed release. When you decide what to fix, give these two rows extra weight.
| No. | Check | Record to open | Scores 2 in a stage when | Who checks it |
|---|---|---|---|---|
| 6 | Own secrets, role-based and logged access | The stage’s secret store entries, role list, rotation dates and access log for the window. | The stage has its own keys, rotated on schedule, and access follows roles. Also, test has no route or key that reaches production. | A security or audit lead reads the role list, then samples the log. |
| 7 | Data that fits the stage | The refresh schedule, the masking or synthetic data method, and a dated sample check. | Production keeps real data under its own controls, while dev and test hold masked or synthetic data. The last sample also found no real values. | The data owner reads the sample record as well as the refresh dates. |
Personal Data Law for Test Copies
For Indian firms, the relevant text is section 8(5) of the 2023 Digital Personal Data Protection Act. Under it, a data fiduciary must safeguard personal data that it possesses or that sits under its control. The Act also names the means: reasonable security safeguards to prevent a breach. However, the section does not name dev or test copies. Treat check 7 as a question for your legal team as well as your engineers. Ask them how the Act treats a customer table copied into test. If a stage runs in the UAE, Saudi Arabia or another GCC state, read that country’s data rules too.
Key Takeaway Checks 6 and 7 outweigh the other rows: a gap there reaches credentials and real data.
Environment Checklist: Catching Differences and Keeping Control
Checks 8 to 11 ask whether anyone notices when a stage moves away from its baseline. They also ask whether each stage has an owner and a way out. NIST SP 800-128 describes configuration monitoring as finding out whether systems match the agreed baseline.
| No. | Check | Record to open | Scores 2 in a stage when | Who checks it |
|---|---|---|---|---|
| 8 | Scheduled comparison with the baseline | The schedule, as well as the output of the stage’s last comparison. | The last scheduled run falls inside the window, and someone acted on each difference. | Another stage’s owner picks one difference from the output and traces it. |
| 9 | Component and schema parity | Production’s component list, the stage’s own list and a schema comparison report. | The stage runs every component on production’s list, unless check 2 records the gap. A tool or script also compared its schema with production’s. | A tester matches the two lists, then opens the schema report. For production, they check its list is current. |
| 10 | Named owner per stage | The owner’s name and initials on this score sheet. | One named person owns the stage and signed its marks this round. | The IT head confirms the name against the team list. |
| 11 | Exit plan | A dated note of the definitions, exports and access needed to move the stage to another host. | The note is current, and the firm holds every item on it. | A procurement lead reads the note and checks who holds each item. |
Check 11 asks only for a note. Take a firm in Bengaluru whose production runs with a hosting supplier in Dubai, for example. Its note would list the exports it holds itself and mark the ones that only the supplier holds.
Fill In the Environment Checklist Score Sheet
Put the stage owners in one room and fill in the grid together. Add a date and initials on every row. The grid works as a dev, test and prod environment checklist template when you keep each dated copy with its records.
| Check | Dev | Test | Prod | Marks equal? | Date and initials |
|---|---|---|---|---|---|
| 1. Inventory per stage | |||||
| 2. Written baseline, with intended differences | |||||
| 3. Configuration in version control | |||||
| 4. Built from one definition | |||||
| 5. Change record, emergency fixes included | |||||
| 6. Own secrets, role-based and logged access | |||||
| 7. Data that fits the stage | |||||
| 8. Scheduled comparison with the baseline | |||||
| 9. Component and schema parity | |||||
| 10. Named owner per stage | |||||
| 11. Exit plan | |||||
| Total (out of 22) | Unequal rows: |
A Worked Example With Invented Marks
We made up the marks below for illustration, and no real firm stands behind them.
| Check | Marks for dev, test and prod |
|---|---|
| 1. Inventory | 2, 2, 2 (equal) |
| 2. Baseline | 1, 1, 1 (equal) |
| 3. Version control | 2, 2, 2 (equal) |
| 4. One definition | 1, 2, 2 (unequal) |
| 5. Change record | 1, 1, 1 (equal) |
| 6. Secrets and access | 0, 1, 2 (unequal) |
| 7. Data | 1, 0, 2 (unequal) |
| 8. Comparison | 0, 1, 1 (unequal) |
| 9. Parity | 1, 2, 1 (unequal) |
| 10. Owner | 2, 2, 2 (equal) |
| 11. Exit plan | 1, 1, 2 (unequal) |
| Totals | 12, 15, 18 out of 22, with 6 of 11 rows unequal |
Add the rows up again before you rely on a total. The five equal rows give 8 in each stage. On top of that, the unequal rows add 4 for dev, 7 for test and 10 for production.
Production comes out on top, and a team could stop reading there. The 0 for test on check 7, though, means the sample found real values in test. That one row outranks the totals. Likewise, a 2, 2, 0 row ranks above a 1, 1, 1 row. The flat row shows the same partial cover in all three stages. The zero, in contrast, shows one stage with nothing at all.
Read the Unequal Rows Before the Totals
Work through the unequal rows in a fixed order. Begin with checks 6 and 7, which settle who can reach a stage and what data it holds. Then take checks 4 and 8. They show whether the stages share a source and whether anyone would spot a change. Finally, sort the remaining unequal rows by their lowest mark.
In the example, the real values in test come first. After that come the shared dev passwords, and then the missing dev comparison. Equal rows wait until those are done, even where all three marks are 1.
A check 4 at 0 in all three stages means the stages have no shared definition to compare against yet. In that case, read how to set up each stage in order first. Come back to the score once a definition exists.
Key Takeaway An unequal row tells you which stage to visit first, whatever the three totals say.
When the Marks Say You Are Ready to Standardize
Bringing the stages in line can start once checks 1, 2 and 10 score at least 1 in every stage. At that point you know what exists, what each stage should be and who owns it. Until then, the inventory and the owners come first. Any plan to standardize earlier would rest on guesses.
The invented example clears this bar. Its rows for checks 1 and 10 read 2, 2, 2, while check 2 reads 1, 1, 1. So the team could start on the unequal rows straight away and bring the baselines up to date at the same time.
Mark the stages again when one of these happens:
- a new stage appears, such as a staging or UAT copy;
- any stage moves to a new host or supplier;
- a stage changes owner;
- a serious incident touches more than one stage.
Otherwise, quarterly is a sensible default. Each score holds for the day you took it. A sheet older than its window says little about the stages now. The ready rule and the quarterly default are Signisys suggestions, open to change.
Where the Score Stops, and When to Bring In Help
A full score on this environment checklist means the stages match on record. However, the release path sits outside it. For merge rules, approvals and rollback, use a list built for scoring the release path itself.
The definition files sit outside it as well. File quality, state handling and rebuild tests have checks on the definition files of their own. For the reasons stages pull apart, read about why stages move apart in the first place.
Some findings need a specialist. A stage nobody will own is one, and real personal data in test is another. A supplier holding the only copy of a definition is the third. Each one needs a decision from someone with authority as well as technical work. Our page on bringing every stage in line with one standard covers the wider work.
Signisys provides these services and has a stake in your reply. Even so, all 11 checks run fine without us. You may want a person outside your team beside you while you open the records. For that, look at configuration automation across stages or ask our DevOps automation team for a first review. No charge, with a fixed scope.
Before You Score: Environment Checklist FAQ
Is a lower dev score a problem if test and production match?
Can the environment checklist take a staging or UAT stage too?
Who marks production when an outside supplier runs it?
How should the team respond when scoring finds real customer data in test?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.