Responding to audit findings on testing and change control
To respond to audit findings on software testing and change control, triage each finding and find its root cause, agree a corrective action plan with an owner and a date per finding, retest the fixed control, run it over a period, and give the auditor, assessor, or bank a closure pack of dated test records per finding.
Findings on testing and change control, with a response deadline
The trigger is a written report with findings and a date for your response. The findings name software change controls: releases without a test record, approvals missing or given by the change author, test logs deleted before the auditor asked, hotfixes deployed outside the pipeline. The CTO or head of engineering owns the fix, the compliance lead owns the answer, and the QA lead owns the proof. Sources on this page were checked on 2026-09-22. The findings usually come from one of three places:
- SOC 2 exceptions in a type 2 report. The service auditor tested sampled changes against criterion CC8.1 of the 2017 Trust Services Criteria, which covers how the entity "authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes". The exceptions stay in the issued report that customers read; criteria and common findings are on the SOC 2 testing requirements page.
- PCI DSS requirements not in place. A Qualified Security Assessor found, for example, that production changes lack the "testing to verify that the change does not adversely impact system security" required by PCI DSS v4.0.1 requirement 6.5.1. Preparation before the assessment is a separate PCI DSS assessment scenario.
- A sponsor bank passes an examiner's finding down. The examiner issues a matter requiring attention (MRA) to the bank. Under the 2023 Interagency Guidance on Third-Party Relationships (88 FR 37920), a bank contract can require "timely remediation if issues arise" (section C.3.e), and the bank monitors remediation, "including actions taken by the third party" (section D.1). The bank's review itself is covered in the sponsor bank compliance audit scenario.
For banks supervised by the Office of the Comptroller of the Currency (OCC) or the Federal Deposit Insurance Corporation (FDIC), a final rule (91 FR 56004, published 1 September 2026, effective 2 November 2026) limits MRAs to practices that could materially harm the institution's financial condition or the Deposit Insurance Fund, and to actual violations of banking law (12 CFR 4.92(c) and 305.1). Under the same rule, a supervisory observation creates no expectation of corrective action, while either agency may still require remediation of an "other violation" (12 CFR 4.92(g) and (h), 305.1(g) and (h)).
What happens when findings get a quick fix and no evidence
- The PCI DSS report stays open. Section 12 of PCI DSS v4.0.1 states that requirements are not in place if controls "are scheduled to be completed at a future date". The entity performs remediation and provides an updated report, and the assessor "will reassess to validate that the remediation is completed". A fix without a retest record gives the assessor nothing to validate, and the Attestation of Compliance waits.
- The SOC 2 exception returns next year. A type 2 opinion covers operating effectiveness throughout the examination period. A pipeline gate added late in the next period leaves most sampled changes under the old process, so the same exception can appear in the second report. Criterion CC4.2 adds a point of focus that management "tracks whether deficiencies are remedied on a timely basis", so an untracked finding weakens a second criterion.
- An MRA escalates. For banks supervised by the Federal Reserve, guidance SR 13-13 states that examiners may elevate an MRA the bank does not address in a timely manner to a matter requiring immediate attention. When follow-up shows unsatisfactory corrective action, additional investigation or enforcement action may be necessary.
- A fix that decays brings a new finding. The Federal Reserve Updated Statement of Supervisory Operating Principles (21 April 2026) tells examiners to rely on the bank's internal audit validation of remediation when it is satisfactory, to terminate an MRA promptly after full remediation, and to issue a new MRA if remediation is not sustainable. For a fintech programme, the bank's internal audit may validate the fix in your systems, and a regression after closure can start a new finding.
How to respond to audit findings, in order
- Register each finding in the auditor's words. Record the source, the criterion, requirement, or MRA reference, the sampled items, and the deadline. Output: a findings register with one owner per finding.
- Reproduce the sampled items. Pull the ticket, approval, CI run, and deployment record for each sampled change, and confirm which element was missing. Output: a fact sheet per finding.
- Find the root cause. Separate design gaps (the pipeline allows a deploy without a passing test run) from operating gaps (the gate exists, but an admin bypass was used). Check CI log retention against the examination period. Output: a root cause statement per finding.
- Write the audit findings corrective action plan. For each finding, state the fix, the owner, the date, the evidence that will prove the fix, and interim targets for long fixes. Agree the evidence with the auditor, assessor, or bank before work starts. Output: a corrective action plan with named owners.
- Fix the control in the pipeline. Enforce branch protection without admin bypass, a required test gate before deploy, a second approver, an emergency path that records tests after release, and log retention longer than the period. Output: change records for each control fix.
- Retest the control. Try to merge your own change, deploy without a passing run, and use the emergency path, then rerun the original failed test cases on the fixed build. Output: Retest evidence after remediation.
- Run the control over a period and sample it. Select changes released after the fix, including hotfixes, and check each for ticket, approval, test record, and deployer identity. Output: a dated operating sample per finding.
- Map each fix to the original requirement. Link the criterion, requirement, or MRA item to its test cases and latest runs. Output: Requirement-to-test traceability matrix.
- Hand over a closure pack per finding. File root cause, fix, retest, and operating sample in the order of the findings register, and list any finding still open with its owner and date. Output: Test evidence pack per audit scope.
Timeline and scope of the response
Durations are typical engineering estimates for findings in one product's release process.
| Phase | Duration (estimate) | Roles | Output |
|---|---|---|---|
| Register and reproduce (steps 1 and 2) | 1 to 2 weeks | QA lead, compliance lead | Findings register and fact sheets |
| Root cause and plan (steps 3 and 4) | 1 to 2 weeks | QA lead, engineering lead, compliance lead | Corrective action plan with owners and dates |
| Control fix (step 5) | 2 to 6 weeks | Platform engineers, product engineers | Change records for each control fix |
| Retest (step 6) | 3 to 5 working days | Test engineers | Retest evidence after remediation |
| Operating period (step 7) | 1 to 3 months, or as the auditor or bank sets | Engineering teams, QA lead | Dated operating sample per finding |
| Mapping and closure pack (steps 8 and 9) | 1 week | QA lead, compliance lead | Test evidence pack per audit scope |
Scope grows with the number of findings, repositories, and deployment pipelines, and with every environment where changes reach production. Design gaps take longer than operating gaps, because the pipeline changes before any evidence exists. Findings from several requesters share one control fix and one retest, with a closure pack in each requester's order. A deadline shorter than the estimate moves the fixes for the highest-risk findings first, and the plan states the remaining dates.
How we help after the report arrives
- QA audit and test strategy covers steps 3 and 4. The QA maturity assessment finds the root cause across the release process, and the Prioritised roadmap with effort estimates becomes the dates in the corrective action plan.
- Audit and certification test evidence covers steps 6, 8, and 9 with Retest evidence after remediation, the Requirement-to-test traceability matrix, and the Test evidence pack per audit scope.
- Test automation covers step 5 with CI pipeline integration with release gates, and the Regression suite for critical money flows keeps the fixed control from decaying.
- Security testing retests PCI DSS penetration test findings and reports Findings with severity, reproduction steps, and retest results.
The service auditor, the Qualified Security Assessor, or the bank decides whether a finding is closed. Our test records are input to that decision.
Questions
What is a matter requiring attention?
What is a corrective action plan?
Plan the response to your audit findings
Send the findings, the sampled items, and the response deadline, and we return a remediation and retest plan with the evidence each finding needs for closure.