Contractor Code Review Checklist for Pull Requests in Regulated Systems
Twenty-one checks in five groups, with the proof to attach to each and the employee who signs.
Free for a work email. Or read the whole checklist on this page.
Every check carries a mark
- Gone
- Attached
A contractor code review checklist covers five things in every pull request. No secrets, no mishandled PII, license-clean code, attached test evidence and sign-off from the employee who owns the component.
Last updated: October 28, 2026
Somebody approved the change. It merged. Six months later an auditor asks what they checked, and the honest answer is that they read it, it looked fine, and nobody wrote down which parts they read or which employee agreed. Not good enough. That answer fails for an employee’s code too, but contractors make it fail faster, because the author leaves on a date and the code stays.
This checklist is the fix. It runs 21 checks in five groups, and each one names the proof to attach and who is allowed to run it, so a reviewer can work down the page in order and a second person can see exactly what was looked at. The bar matches the one you hold employees to. What changes is the last group, because the person who signs for a merge has to be someone who will still be here when the contractor isn’t.
I wrote about how fast a contractor should earn the right to merge alone in contractor code review without becoming the bottleneck. This page is the list you run on each pull request. For the ownership question, read who owns contractor code. If you’re still weighing the model, software development staff augmentation explains how these engagements run.
Download the Contractor Code Review Checklist
One work email and the printable PDF and the editable Word file are yours, with the same 21 checks as the page below and a blank to fill beside each one.
Twenty-one checks
Five groups, each check marked gone or attached, with the proof to keep and who runs it.
Blanks you fill in
Pull request, repository, author, reviewer and owner on top, and a box beside every check.
A ready-to-merge block
Three signature lines for the author, the reviewer and the employee who owns the code.
Where should we send it?
Work email, please. We use your details to respond to this request. See our privacy policy.
Your checklist is ready
Print the PDF for the review desk, or fill the Word file in the pull request itself.
Next
Need contract engineers who start in days? Tell us the roles, your stack and the start date.
The Contractor Pull Request Review Checklist
Run it on every pull request a contractor opens. Read a pull request the way you read a diff, asking what must be gone and what must be attached.
The diffstat, group by group
- 1Secrets and credentialsDoes anything in this change open a door it should not?3 gone, 2 attached
- 2PII handlingCould a real person be identified from this change?3 gone, 1 attached
- 3Licensing of pasted and AI-generated codeWhere did this code come from, and may we keep it?2 gone, 2 attached
- 4Test evidenceWhat proves this works, and where is the proof?1 gone, 3 attached
- 5Owner sign-offWhich employee signs for this merge?1 gone, 3 attached
A hatched square is a check for something that must be gone from the pull request. A solid square is a check for something that must be attached to it. Twenty-one checks, 10 gone and 11 attached.
Pull request review · template
Contractor pull request, one review
How to read a line
- GoneYou are looking for something that must not be in the pull request.
- AttachedYou are looking for proof that must be on the pull request.
- Employee ownerOnly an employee who owns the code can run or sign this one.
| Mark | Check | Proof to attach | Who |
|---|---|---|---|
| 1Secrets and credentials3 gone, 2 attachedNothing that opens a door is in the diff, the history or the fixtures. | |||
| S1Gone | No keys, tokens, passwords or private keys in the diffThat includes test fixtures, sample config and a pasted curl command. If it opens something, it does not belong in a commit. | Secret scan passed on the pull request | Any reviewer |
| S2Gone | No secrets anywhere in the branch historyA secret deleted in the last commit is still in the one before it. Scan every commit on the branch, not only the final diff. | Scan covers all commits on the branch | Any reviewer |
| S3Gone | No environment files or local config committedA .env file, a keystore or a downloaded credentials file is a leak waiting for a push. Sample files hold placeholders only. | File list checked against the ignore rules | Any reviewer |
| S4Attached | Any new secret is requested through the secrets managerThe description names the secret, where it lives and which employee rotates it. The contractor never holds the production value. | Request or ticket linked in the description | Employee owner |
| S5Attached | A push protection bypass has a reason an employee has readBy default anyone with write access can bypass the block by giving a reason, so someone other than the author reads the reason. | Bypass reason seen in the alert log | Employee owner |
| 2PII handling3 gone, 1 attachedNo real customer data in the code, the logs or the tests, and a clear path for the data that is meant to be there. | |||
| P1Gone | No real customer data in tests, fixtures, screenshots or logsUse synthetic records. A production export pasted into a test file puts real data in version control for good. | Fixtures and screenshots read, synthetic data only | Any reviewer |
| P2Attached | New fields that hold personal data are listed in the descriptionName the field, where it is stored, who can read it and how long it is kept. | Field list in the pull request description | Employee owner |
| P3Gone | No personal data in log lines, error messages or analytics eventsNames, emails, account numbers and government IDs stay out. Log an internal ID instead. | Every new log line read in the diff | Any reviewer |
| P4Gone | No new path for personal data to leave the systemNo new third-party call, SDK, export job or webhook that carries customer data unless the owner approved it. | New outbound calls listed and approved | Employee owner |
| 3Licensing of pasted and AI-generated code2 gone, 2 attachedEvery block of code has a known origin and a license you can live with. | |||
| L1Gone | No pasted code of unknown originA snippet from a forum, a gist or another repository names its source and license in the description, or it comes out. | Source and license written beside the snippet | Any reviewer |
| L2Attached | New dependencies pass the license checkEach new package is on the approved list. Copyleft licenses such as GPL and AGPL go to counsel before they go into a closed-source product. | License scan result attached | Any reviewer |
| L3Attached | AI-generated code is disclosed, and the author owns every lineThe description says which parts a tool wrote, the tool is on the approved list, and the author can explain each line. | Disclosure line in the description | Any reviewer |
| L4Gone | No license headers or notices removed or alteredVendored code keeps its license file. Copyright lines stay as the source had them. | Headers compared with the source | Any reviewer |
| 4Test evidence1 gone, 3 attachedThe proof is a link anyone can follow, not a sentence anyone can type. | |||
| T1Attached | Tests cover the changed behavior, including the failure pathA test for the happy path proves only that the code works when nothing goes wrong. | New or updated tests in the diff | Any reviewer |
| T2Attached | CI is green on the final commitNot on an earlier one. A push after the green check reopens the question. | Link to the run for the head commit | Any reviewer |
| T3Gone | No tests that call real production services or use real dataTests run against fakes, sandboxes or synthetic records. | Test setup read in the diff | Any reviewer |
| T4Attached | The author says how they tested by handEnvironment, steps and result, in the description. Development or staging, never production. | Manual test note in the description | Any reviewer |
| 5Owner sign-off1 gone, 3 attachedAn employee who owns the code approves it, after the last commit, and the record stays. | |||
| O1Attached | An employee who owns each touched path is namedThe owner is an employee with write access to the repository, named in CODEOWNERS or in the description. | CODEOWNERS entry or a named owner | Employee owner |
| O2Attached | The owner approves after the last commitDismiss stale approvals, so a change pushed after the approval gets looked at again. | Approval dated after the head commit | Employee owner |
| O3Gone | No self-approval, and no contractor approval counted as owner sign-offA contractor’s review is welcome and useful. It just is not the signature. | Required reviews set to code owners | Employee owner |
| O4Attached | The merge record is kept where an auditor can find itThe pull request, approvals, scan results and test run stay linked for as long as your policy says. | Retention written in the team’s working agreement | Employee owner |
Ready to merge
- AuthorI ran these checks and attached the proof.
- ReviewerI reviewed this change against the checklist.
- Employee ownerI own this code and I approve the merge.
The diffstat
- 11checks look for proof that must be attached
- 10checks look for something that must be gone
- 8checks need an employee who owns the code
Mark each box when the proof is attached to the pull request itself, not in a chat thread. Any reviewer can run a line marked Any reviewer. A line marked Employee owner needs the employee who owns the code. The sheet is a template, so change it to fit your stack and your policy. For the security side of the same reading, OWASP maintains a Code Review Guide.
What Should You Check for Secrets in a Contractor’s Pull Request?
Scan first. Then read the history. GitHub’s push protection blocks supported secret types before they are pushed, but by default anyone with write access can bypass the block by giving a reason, which is a sensible default for employees and a gap when the author is a contractor you met last week. Check S5 exists so that someone besides the author reads that reason.
A scan of the final diff misses the secret that was deleted in the last commit and still sits in the one before it, so scan every commit on the branch. If a real credential ever reached a branch, rotate it. Treat it as exposed. The OWASP Secrets Management Cheat Sheet notes how many organizations still hardcode secrets in source and configuration files, and that habit is exactly what these checks are there to catch.
PAYMENTS_API_KEY = "paste-key-here"PAYMENTS_API_KEY = os.environ["PAYMENTS_API_KEY"]The contractor writes the request for a new secret. An employee owns it.
How Do You Check a Pull Request for PII?
Personal data hides in four places. Fixtures, log lines, error messages and the screenshots pasted into the description. Look there first.
Logs deserve the most suspicion. The OWASP Logging Cheat Sheet warns that logs may contain personal and other sensitive information, and it suggests de-identifying data wherever the person’s identity isn’t needed, which is cheap to do at write time and expensive to undo after the logs have shipped to a vendor. That is check P3. Log an internal ID instead of an email.
log.info("paid invoice for %s", user.email)log.info("paid invoice for user %s", user.id)Then ask where the data goes. A new SDK, an export job or a webhook can carry customer data out of the system without touching a table, so check P4 asks the owner to approve every new path. Your own policy decides what counts as protected data, whether that is GLBA, HIPAA or PCI DSS. The check only makes sure somebody asks.
What Do You Check for Pasted and AI-Generated Code?
Two questions get mixed up here. May we use this code, and who owns it? The reviewer answers the first.
The second belongs to your contract and your counsel, and who owns contractor code explains why a paid invoice doesn’t settle it. What a reviewer can do is make sure every block of code arrives with a known origin.
- Pasted snippets. A block from a forum, a gist or another repository names its source and license in the description, or it comes out.
- Each new dependency is checked against your approved list, with its license written as an SPDX identifier so a scanner and a person read the same thing.
- Which parts did a tool write? The description says, the tool is on the approved list in the contract, and the author reads and owns every line.
Why not ban it
AI-generated code deserves no special suspicion and no special pass. It fails the way plausible code fails, quietly, so ask the author to point at it. Your policy shouldn’t care who typed a line. For where an AI reviewer fits before the human one, see AI code review for engineering teams.
116 days
the median length of a KORE1 contract assignment, counted over 1,887 assignments
3 days
the median wait between an accepted offer and the first shift, counted over 1,997 starts
1,040 hours
of work after which a KORE1 contractor can convert to your team at no fee
37.5%
of KORE1 contract placements convert to a permanent hire, counted over 552 placements
Figures come from KORE1 contract placements across all roles, the same records behind the Contract Rate Index 2026-Q4. The sample size sits beside each count, so you can judge how much weight it bears. The 1,040-hour threshold is our conversion policy and not a measurement. The point is simple. The assignment ends and the code stays.
What Counts as Test Evidence on a Pull Request?
A link counts. A sentence doesn’t. “Tests pass” typed into a description is a claim, and the CI run on the final commit is evidence.
T1 and T2
The run, linked
Tests for the changed behavior, including the failure path, and a green CI run on the head commit, not an earlier one.
T4
The hand test, written
The author says what they tried, where and what happened, in development or staging, never in production.
T3
The fakes, on purpose
Nothing in the test suite calls a real production service or reads real customer records.
Keep the failure path honest. A test for the happy path proves the code works when nothing goes wrong, and production is mostly the other days. Check T1 asks for the failing case on purpose.
Evidence also has a shelf life. Link the run, the scan and the approvals from one place and keep them as long as your policy says, because the auditor’s question arrives long after the contractor’s last day. Keep the links.
Who Signs a Contractor’s Merge? Decision Ownership at the Merge Button
A merge is a decision, and every decision needs an owner. A contractor can write the change, review a peer’s and catch things an employee would miss. The signature that counts belongs to an employee who owns the code, because that person will still be here after a 116-day assignment ends, and will be the one answering when somebody asks why that change went out on a Friday.
Make the tool enforce it. GitHub’s CODEOWNERS file maps paths to the people responsible, code owners need write access, and they aren’t requested automatically on a draft pull request, so a draft can sit unseen. The trust ramp and the branch settings are in my piece on reviewing contractor code. Put who can merge what on the same map as every other call, the decision ownership diagram.
Devin Hornick, a KORE1 partner, describes the arrangement plainly.
“Hourly, which we prefer. It’s really more of a staffing model to do the hourly billing and you manage the person.”
Devin Hornick, KORE1 partner
You manage the person, so the review is yours. A staffing firm can send you a good engineer. It can’t sign your merge.
How KORE1 Sources, Vets and Places the Contract Engineers This Checklist Assumes
This part is us. Not Kris. A checklist assumes an engineer who reads a review comment and attaches the proof, so here is what we do on our side of the table.
Sourcing
Screened by people who ship
Candidates for regulated roles are screened by engineers who have shipped under SOC 2, HIPAA, PCI DSS and TRID.
How we screen for regulated workVetting
A recruiter has spoken to them
A KORE1 recruiter talks with every candidate before you do, so your first call is never their first conversation about the role.
Contract engineering teamsPlacing
W2 contractors with dates on paper
KORE1 is the W2 employer of record, so every assignment has a start date and an end date, and the code outlives both.
How contract staffing works
Across our engineering searches we average 17 days to hire, and 92% of KORE1 placements are still in the seat twelve months on, which matters for this checklist, because an engineer who stays learns which of the 21 checks your codebase fails most often. About 37.5% of our contract placements convert to a permanent hire (n=552), which makes every pull request a small interview for both sides, since the engineer is showing how they handle review and you are showing how your team gives it. We place engineers through software development staff augmentation, under our wider engineering staffing practice, and the model behind it is on the contract staffing page.
Common Questions
What should I check in a contractor’s pull request in a regulated codebase?
Check five things. No secrets or credentials, correct handling of PII, license-clean code, attached test evidence, and sign-off from the employee who owns the component. The bar matches employee code, and the owner sign-off is the part that changes.
Should a contractor’s code get a stricter review than an employee’s?
No. The bar is the same for everyone, because a stricter one tells a good engineer you don’t trust them before they have written a line, and a lighter one ships worse code to the people who have to live with it. What differs is who signs. Anything that touches money, personal data or production needs an employee owner on the approval, whoever wrote it.
Can a contractor approve another contractor’s pull request?
They can review it, and the review helps. It just can’t be the owner sign-off. Set required reviews to code owners, so a contractor’s approval alone never satisfies the merge rule on code that touches regulated data. Two contractors agreeing is still two contractors.
What if the scan finds a real credential?
Rotate it first. Remove it second. A credential that reached a branch is exposed even after the commit is deleted, because history, forks and clones keep copies, so the only safe assumption is that someone already has it. Then find out how it got in. Push protection can be bypassed by anyone with write access, so read the bypass reason.
Do contractors have to disclose AI-generated code in a pull request?
Your contract and your policy decide. Ask for it. A line in the description tells the reviewer where to spend attention, and the author still owns every line. Think of the disclosure as a pointer, not a confession.
Need Contract Engineers Who Start in Days?
Tell us the roles, your stack and the start date. A KORE1 recruiter takes the req from there.
Find Contract Engineers →Not yet? Download the checklist first.
