A self-identified issue is a control weakness, error or breach that management found, documented and put into motion before internal audit, the external auditor or a regulator found it. “Documented and in motion” is the test, and it is a strict one: an issue statement, the population affected, a cause, a named owner, dated actions and an entry in the issue system that predates the audit. Meet that test and most audit functions report the issue with a management-identified label, keep it out of the engagement rating or weight it lighter, and validate it by inspection rather than re-performance. Fail it, and the same problem comes back as an audit finding whose cause statement now contains the words “management was aware.”
The case for telling audit first is not only about tone. The Global Internal Audit Standards require the final engagement communication to acknowledge actions management has already started or completed (Standard 15.1). The written record is most explicit in US banking: the OCC’s current Matters Requiring Attention manual requires every MRA to state whether the concern is self-identified, and calls a bank’s action to self-identify and remediate an important consideration in assessing corrective action, and the interagency consumer compliance rating system says plainly that it provides incentives for self-identification. Those are bank-sector sources, but the logic they write down is the one every audit function applies, which is why the Being Audited? hub opens its answer to “should I tell them about a problem they have not found” with the word yes.
This guide is the full case and the mechanics: what the label means and who grants it, how audit functions and regulators treat a self-identified issue, what qualifies, how to document and log one, what happens when audit tests it, when to raise it, when it backfires, and a quarterly routine so the next issue is found by you. It builds on the heads-up habit described in living with internal audit year-round and on the craft of management action plans that close.
In this guide
- What a self-identified issue is, and the variants
- How audit functions treat a self-identified issue
- What regulators say about self-identification
- Found by audit versus found by you: the economics
- What qualifies, and what does not
- How to document one: the template
- Where to log it, and in what order
- What happens when audit tests your self-identified issue
- Timing: planning, fieldwork or after
- When self-identification backfires
- Building the routine: the quarterly self-check
- Worked example: Westbrook Savings Bank
- Questions readers ask
- Related guides
What a self-identified issue is, and the variants
The Standards do not define the term. It comes from issue-management methodologies, bank supervisory manuals and SOX programs, which is why the labels vary from one organization to the next and why a manager hearing “that would count as self-identified” should ask what the local methodology actually says. The working definition most functions use has four parts, and all four have to hold. First, the issue was found by management or by management’s own second-line functions, not by internal audit, the external auditor or a regulator. Second, it is written down as an issue: what is wrong, against what requirement, affecting what population, since when, caused by what. Third, it is in the system of record (the issue log or GRC platform) with a date that precedes audit’s work in the area. Fourth, it is being worked: an owner, actions with dates, and interim mitigation if the fix will take time.
Everything short of that is something else. A problem the team talks about is a known issue. A problem the manager mentions in the walkthrough is a disclosure, and it helps, but it is not a self-identified issue until it is recorded. A problem that was logged two years ago and never fixed is an overdue action, and the label stops protecting it.
| Term | What it usually means | Who records it | How it is typically treated |
|---|---|---|---|
| Self-identified issue (SII) | Found by the business or its second line, documented and logged before audit or a regulator raised it | The owner, in the issue log, with source “self-identified” | Reported with the label; often excluded from the engagement rating; validated by inspection |
| Management-identified issue (MII) | Same concept; the label some functions use in reports (“issues identified by management during the review”) | Audit records it in the report; the owner records it in the log | Acknowledged under Standard 15.1; may or may not be rated |
| Second-line-identified issue | Found by compliance, operational risk or a control-testing team rather than the first line | The second-line function, in its own issue register, assigned to a business owner | Counts as self-identified toward audit and regulators; audit may rely on the second line’s work under Standard 9.5 |
| Self-reported or self-disclosed | The organization tells a regulator or external party about a problem before they find it | Compliance or legal, through a controlled channel | Credited explicitly in several supervisory frameworks; a decision above a line manager’s authority |
| Surfaced during fieldwork | Management raises a problem after the audit has started but before auditors test the area | Audit documents it; the owner should log it the same day | Gray zone: usually acknowledged as management-identified if not already under test, and the report says so |
| Known issue or watch item | Something the team knows is weak but has not written up with an owner and actions | Nobody, which is the problem | Not self-identified; if audit finds it, awareness becomes part of the cause |
| Repeat or overdue self-identified issue | A logged issue whose actions have missed their dates | The issue log, with aging from the original date | The label no longer softens anything; often re-rated and reported as overdue |
One more distinction clears up most of the arguments about the term: “self” is relative to whoever is asking. Inside the organization, self-identified means the business found it rather than internal audit. To a bank supervisor, self-identified means the bank found it rather than the examiner, and the bank includes its audit function. The OCC’s MRA manual defines it that way: the bank initially discovered the violation or practice, “such as through independent risk management or internal audit,” and disclosed it to the OCC before the OCC identified it. So a finding that is an audit finding on the inside is a self-identified matter on the outside. That is why internal audit wants you to find issues before audit does, and why audit wants to find issues before examiners do; the incentive runs the same direction at every level of the three lines.
| Who is asking | “Self” means | “Found by someone else” means | Where the label shows up |
|---|---|---|---|
| Internal audit | The first line or second line found it | Internal audit found it in planning, fieldwork or follow-up | The engagement report and the issue log source field |
| The audit committee | Management or audit found it | The external auditor or a regulator found it | The quarterly pack, often as a separate line for self-identified items |
| A bank supervisor | The bank found it, including through risk management or internal audit, and disclosed it | Examiners found it | The MRA attributes (new, repeat, self-identified, past due) and the examination report |
| The external auditor (SOX) | Management’s own controls or testing found the deficiency or misstatement | The auditor found it in circumstances suggesting the controls would not have | The deficiency evaluation; a material misstatement found by the auditor in those circumstances is an indicator of a material weakness |
How audit functions treat a self-identified issue
Three things are close to universal. The issue is reported, not buried: a self-identified issue that is material to the engagement’s objectives appears in the report, because the report describes the state of the controls and the issue is part of that state. It is labeled: either in a separate section, often headed “issues identified by management,” or inside the finding with a sentence that management identified the condition on a given date and had corrective action under way. And it is tracked to closure like any other issue, with the lighter validation described in the issue log template, typically inspection rather than re-performance, because the owner has already done the investigative work and audit’s job is to confirm it.
What varies is the rating treatment, and this is where you need to read your own organization’s methodology rather than assume. Practitioner judgment, from the methodologies I have worked under and reviewed: there are three common models, and a function usually runs one of them consistently.
| Model | How the issue appears in the report | Effect on the engagement rating | What still applies |
|---|---|---|---|
| Separate and unrated | A distinct section listing management-identified issues with status, no severity rating | None, provided the issue was logged before audit’s work and actions are on track | Audit may still test the extent and the fix; an overdue action pulls the issue into the rated findings |
| Rated but excluded | Rated on the normal scale, flagged as management-identified | Excluded from the aggregation rule that sets the overall rating | The committee sees the rating; a High self-identified issue still draws attention and a short deadline |
| Rated and counted, with the label | Treated as a finding, with a sentence crediting management’s identification and progress | Counts toward the overall rating, sometimes with a one-notch allowance for credible progress | The label still changes how the committee reads the page, and the cause statement does not include “management unaware” |
Two rules hold under every model. The risk does not change because of who found it: an open exposure rated High on your severity matrix is still High, and a self-identified High gets a short deadline and executive attention, not a pass. And the label is earned by the record, not by the conversation: audit will look for the dated entry, the population analysis and the action plan, and the issue log guide’s rule that a self-identified issue must never pre-empt a finding exists because managers have tried to log one the day after a walkthrough exposed it.
Several Standards shape this treatment. Standard 15.1 requires the final communication to acknowledge actions management has already started or completed, which is the formal reason a credible self-identified issue cannot be written up as if audit discovered it cold. Standard 14.3 requires auditors to work with management to identify root causes where possible and to evaluate significance, so an owner who arrives with a cause analysis is doing part of the auditor’s work and will usually be met halfway. Standard 9.5 (Coordination and Reliance) governs when internal audit may rely on the work of other assurance providers, including the second line, which is why an issue raised through operational risk or compliance often carries more weight than one raised in a hallway. And if you decide not to fix a self-identified issue, that is risk acceptance, with its own record and authority ladder, not a quiet closure; under Standard 11.5, an acceptance that takes the organization beyond its risk appetite is escalated by the chief audit executive to senior management and, if unresolved, to the board.
In US banks subject to the OCC’s heightened standards, the quality of management’s own issue identification is itself a reported subject. Appendix D to 12 CFR Part 30 has internal audit report to the audit committee on how effectively front line units and independent risk management identify and resolve issues in a timely manner, and has front line compensation consider the issues that risk management and audit find and how quickly they are corrected. The Federal Reserve’s SR 13-1 expects the audit committee to receive, at least annually, internal audit’s opinion on risk management processes, including the effectiveness of management’s self-assessment and remediation of identified issues. In a supervised bank, then, how well your unit finds and fixes its own issues is a line in internal audit’s report to the committee, and in the largest banks it is meant to count in your pay. The next section quotes the sources.
What regulators say about self-identification
The supervisory record is explicit, and it is worth quoting accurately because managers in regulated firms hear vague versions of it. The sources below are US bank and consumer-finance supervisory documents, plus the PCAOB standard that governs SOX audits of public companies. If you work outside those sectors, read them as the clearest written statement of a logic every assurance provider applies, and check what your own regulator has published before quoting any of it. The table gives the gist of each source and what it means for a line manager. One caution: self-reporting to a regulator is a decision for compliance, legal and senior management, made through a controlled channel. Your part is to log and escalate internally, fast and in writing, so that the people with that authority can make the decision with the facts in front of them.
| Source | What it says (gist, with short quotations) | What it means for a manager |
|---|---|---|
| OCC, PPM 5400-11, Matters Requiring Attention (the version current as of November 2026, revised August 27, 2026) | Defines self-identified as the bank initially discovering the violation or practice, “such as through independent risk management or internal audit,” and disclosing it to the OCC before the OCC identified it. Each MRA “must indicate whether the concern is new,” repeat, self-identified or past due. A bank’s action to self-identify and remediate “is an important consideration when assessing the appropriateness of any corrective action.” Self-identification “does not affect whether it is a substantive or other violation.” Examiners consider how remediation efforts reduce the likelihood of material harm when judging whether a practice meets the MRA standard. | The label follows the issue all the way to the examination report. Remediation already under way is weighed. But a violation is still a violation; self-identification changes the response, not the fact. |
| OCC heightened standards, 12 CFR Part 30, Appendix D (banks with average total consolidated assets of $50 billion or more, and smaller banks whose parent company controls a covered bank) | Front line units should assess their material risks on an ongoing basis. Internal audit’s reports to the audit committee should include a determination of the effectiveness of front line units and independent risk management “in identifying and resolving issues in a timely manner.” Front line compensation plans should consider the level and severity of issues identified by independent risk management and internal audit and the timeliness of corrective action. | In a covered bank, issue identification by the business is measured, reported upward and connected to performance management. |
| Federal Reserve, SR 13-1, Supplemental Policy Statement on the Internal Audit Function (January 2013; attachment revised October 2025) | The audit committee should receive at least annually internal audit’s opinion on the adequacy of risk management processes, “including effectiveness of management’s self-assessment and remediation of identified issues.” Internal audit may consider a management risk and control self-assessment in developing its own risk assessment. | Your RCSA and your issue log are inputs to audit’s planning and to its annual opinion on you. |
| FFIEC Uniform Interagency Consumer Compliance Rating System (approved 2016, effective March 31, 2017) | “Strong compliance programs are proactive. They promote consumer protection by preventing, self-identifying, and addressing compliance issues in a proactive manner. Accordingly, the CC Rating System provides incentives for such practices through the definitions associated with a 1 rating.” When violations involve limited consumer impact, “were self-identified, and resolved promptly, the evaluation may result in a 1 or 2 rating.” Board and management oversight is assessed partly on self-identification of compliance issues and corrective action. | For consumer compliance issues, who found it and how fast it was fixed feed directly into the institution’s rating. |
| CFPB Bulletin 2020-01, Responsible Business Conduct (March 6, 2020; listed without a rescission notice as of November 2026) | Four factors: self-assessing, self-reporting, remediating and cooperating. The Bureau could “close an enforcement investigation with no action or decide not to include Matters Requiring Attention in an exam report or supervisory letter.” It asks whether the entity proactively self-reported “or wait[ed] until discovery or disclosure was likely to happen anyway.” | The timing test regulators apply is the same one audit applies: before they would have found it, or after. |
| PCAOB AS 2201, paragraph .69 (SOX integrated audits) | Indicators of a material weakness include “identification by the auditor of a material misstatement” in circumstances indicating it “would not have been detected by the company’s internal control over financial reporting.” | In SOX, who caught the error is built into severity: a misstatement caught by your controls is evidence they work; one caught by the auditor is evidence they do not. |
Notice what none of these sources says. None says a self-identified problem disappears, is unreportable, or is excused from remediation. The OCC is blunt that self-identification does not change whether a violation is substantive. The credit is for finding it, fixing it and saying so; the exposure is still the exposure. Managers who read “self-identified” as “forgiven” are reading a different document. If your organization is a bank, the MRA and MRIA explainer covers how examiner findings escalate and why the self-identified attribute matters so much at that level.
Found by audit versus found by you: the economics
Put the same issue through both doors and compare what comes out. The exposure is identical: say, a dual-approval threshold set wrong for eleven weeks. The difference is in everything that surrounds it, and the largest difference is the one managers underestimate: the cause statement. When audit finds an issue that management did not know about, the cause is a control gap. When audit finds an issue that management did know about, the cause is the control gap plus the failure to escalate and act, and that second cause is a governance issue that attaches to you personally rather than to the process. Auditors are trained to write cause statements that point to the fix, and the fix for “management knew and did not act” is about management.
| Dimension | Found by internal audit | Self-identified, documented and in motion |
|---|---|---|
| How it reads in the report | A finding with condition, criteria, cause, effect and recommendation; your response underneath | A management-identified issue with status, or a finding that opens by crediting your identification and progress |
| Cause statement | The control gap, plus “not detected by management monitoring” | The control gap only; your own cause analysis is usually adopted |
| Issue rating | Per the matrix, often with a notch for duration and the fact nobody noticed | Per the matrix for the open exposure; duration already truncated by your interim fix |
| Engagement rating | Counts fully toward the overall rating | Excluded or weighted lighter under most methodologies (check yours) |
| Action plan | Written under deadline during the draft-report window, often negotiated | Already written, by you, on your timeline, before anyone was negotiating |
| Validation at closure | Re-performance or sample testing by audit | Typically inspection of your evidence, with a smaller sample if any |
| Audit committee view | Another finding in your executive’s area | A line in the self-identified count, which committees read as control-environment health |
| Next audit cycle | Your area’s risk assessment score rises; a shorter interval and a longer request list | Credibility banked; auditors who learn about your problems from you test with less suspicion |
| Regulatory optics (where relevant) | An examiner reading the audit report sees an issue audit found and management missed | The attribute “self-identified” follows the issue if it ever becomes an MRA |
| Your time | Fieldwork requests, a validation meeting, a draft-report scramble, then remediation | Remediation, plus one well-written record and one email |
There is a second-order effect that does not fit in a table. Auditors calibrate their skepticism to the person in front of them: a manager who has sent two or three well-documented self-identified issues in the past year is a manager whose walkthrough statements get believed and whose evidence gets accepted on first submission. That reputation is built in the off-season, which is the point of the year-round guide, and it is spent, fast, by one issue audit discovers that you already knew about.
What qualifies, and what does not
The qualifying test is the one from the opening: found by you, written up, logged before audit’s work, being worked. Each row of the table below is a conversation I have had in a closing meeting; the right-hand column is what the auditor says when the manager claims the label and the record does not support it.
| Qualifies | Does not qualify | What the auditor will say |
|---|---|---|
| An issue record dated before the audit notification, with population, cause, owner and actions | “We’ve known about that for a while” said in the walkthrough | Awareness without a record is part of the cause, not a credit |
| A problem your second line found in its testing and assigned to you, with your action plan attached | A second-line observation you disputed and left unassigned for six months | The second line identified it; you did not act. The source is second line, the status is overdue |
| Full extent established: you pulled the population, not the one instance that surfaced | The single instance that prompted the question, with “we assume it’s isolated” | We will pull the population; if it is bigger, the finding is ours for the difference |
| Actions that address the cause (the parameter checklist, the missing reconciliation step) | Actions that address the symptom (“reminded the team”, “will be more careful”) | The action plan does not address the cause; we will write a recommendation |
| Interim mitigation in place from the day of discovery, with evidence it is operating | A fix scheduled for the next release with nothing in between | The exposure is open today; the rating reflects an unmitigated risk |
| Logged with your executive and the second line informed, in writing, within days | Logged in a personal spreadsheet nobody else can see | A record nobody can see is not an issue management process |
| Raised before audit requested the related evidence or walked the related process | Logged the morning after the walkthrough exposed it | Audit was already testing the area; the finding is audit’s and the source will say so |
| An issue whose fix is on time, or whose date was revised through the proper extension process | A self-identified issue two years old with three silent date changes | This is an overdue action; the label expired with the first missed date |
Two edge cases deserve a sentence each. An issue you found and partly fixed before audit arrived still qualifies if the record shows the dates; the report will say “management identified and remediated,” which is the best sentence a manager can have written about them. And an issue your own team surfaces during fieldwork, in an area audit has not yet tested, usually earns the label if you log it that day and tell the lead auditor, because the alternative teaches everyone to stay quiet until the closing meeting; the timing section below shows where that line falls.
How to document one: the template
Write the record the way audit would write the finding, because that is how it will be read. The structure is the familiar one of condition, criteria, cause and effect, with the two additions that make it self-identified rather than merely identified: how and when you found it, and what you have already done about it. If your issue system has fixed fields, map these onto them; if it does not, the table is the record. Keep the prose short and the facts dated.
| Field | What to write | Example (hypothetical) |
|---|---|---|
| Title | Control, failure, period, in one line | Outbound wire dual-approval threshold set above policy, 14 March to 2 June |
| Issue statement (condition) | What is happening versus what should happen, with numbers | Wires between $25,000 and $100,000 released with one approver; policy requires two above $25,000. 1,284 wires affected over eleven weeks |
| Requirement (criteria) | The policy, procedure, regulation or control description breached, by reference | Payments Policy 4.2, dual authorization above $25,000; key control PAY-07 |
| How and when identified | Who found it, how, on what date; attach the evidence of discovery | Team lead investigating a customer query noted a single-approver release on 2 June; escalated to manager same day (email attached) |
| Population and extent | How you established the full extent; the query, the period, the count | Query of all wires 14 March to 2 June with amount between thresholds, run with IT on 3 June; parameters attached |
| Impact so far | Losses, errors, customer or regulatory effect found, with the look-back method | Look-back of all 1,284 wires to customer instructions completed 20 June; no unauthorized wires; three late callbacks noted |
| Root cause | The process or design reason, not the person | Core upgrade change ticket required no post-implementation check of control parameters; vendor template reset the threshold to its default |
| Interim mitigation | What reduced the risk from the day of discovery, who runs it, until when | Parameter corrected 2 June 15:40 and verified with a test wire; daily supervisor review of all wires above $25,000 until action 2 is live |
| Corrective actions | Each action with owner, date and the cause it addresses | 1. Control-parameter checklist added to change procedure (IT change manager, 31 July). 2. Quarterly parameter attestation added to key control list (payments manager, first run 30 September). 3. Look-back of all affected wires to customer instructions (payments manager, 20 June) |
| Evidence of completion | What you will show when you call it done | Approved procedure with checklist; first completed attestation with system screenshots |
| Proposed rating | Your rating on the organization’s scale, with the reasoning | Medium: key control, no loss, exposure closed on discovery, eleven-week duration |
| Reported to | Who was told, when, in what form | SVP Operations 2 June; Operational Risk 3 June (event record OR-2211); Internal Audit 4 June (email with this record) |
| Status and review | Current status and next review date | In progress; actions 1 and 3 complete; next review 30 September |
Three sentences carry the credibility of the whole record. The discovery sentence, with a date and a named mechanism, because it is the evidence of self-identification and audit will test it. The population sentence, because the difference between “one wire” and “1,284 wires” is the difference between an anecdote and an issue, and because auditors who have to establish the extent themselves tend to own the finding. And the cause sentence, which should name a process or a design choice rather than a person; a cause that reads “the analyst failed to” invites the question of why the control depended on one analyst. The owner’s guide to root cause analysis shows how to reach a cause auditors accept in a week, and the auditor-side 5 Whys worked examples show how the question gets answered when audit does the analysis instead of you.
Proposing your own rating is optional and, in my judgment, worth doing. It shows you have read the methodology, and it anchors the discussion. Use the organization’s definitions, not your sense of how bad it feels; the ratings decoder for auditees shows how to read those definitions and argue from them. If the issue is in a SOX key control, say so and copy whoever runs the program, because the deficiency evaluation for ICFR runs on its own track and its own timetable.
Where to log it, and in what order
Order matters, and the order is nearly always the same: your own management first, the second line and the system of record the same day or the next, internal audit within the week. Telling audit before your own executive is the one sequence that reliably goes wrong, because the executive hears about a problem in their area from the chief audit executive, and no label repairs that. The table shows each destination, what logging there does for you, and what it does not.
| Destination | When | What it does for you | What it does not do |
|---|---|---|---|
| Your executive | Day of discovery, verbally, then the record in writing | Keeps the chain of command intact; secures resources and air cover | Does not create a record audit can rely on by itself |
| The issue log or GRC platform | Within one or two working days | The dated entry is the evidence of self-identification; it drives tracking and reporting | Does not close anything; the entry starts the clock on your actions |
| Second line (operational risk, compliance, control testing) | Same day as the log entry; immediately if there is a loss, customer impact or possible breach | Creates the loss or event record where one is required; the second line’s involvement adds weight toward audit and regulators | Does not transfer ownership; the action plan is still yours |
| Internal audit | Within the week; the same day if the area is in the current audit plan | Earns the label; enters the planning file; prevents the “nobody told us” cause | Does not make audit the owner, the validator of your evidence yet, or a party to the fix |
| SOX program office (if a key ICFR control) | Immediately; deficiencies are evaluated on the program’s timetable | Gets the deficiency evaluated and, if needed, remediated before period end | Does not substitute for the operational issue log |
| Legal and compliance (possible regulatory breach, customer harm, fraud) | Immediately, before any wider circulation | Puts the regulatory self-reporting decision where it belongs | Does not relieve you of the internal logging; both happen |
The email to audit should be short, factual and attached to the record. A format that works: one paragraph stating what was found and when, one stating what has been done and what is planned, one stating where it is logged and who else has been told, and the record attached. Address it to the auditor who covers your area or to the audit manager you met in the last engagement, and copy your executive. Do not ask audit to agree the rating or bless the plan in that email; ask whether they want anything else and whether they would like a walkthrough of the fix when it is live. Asking for advice before you build is a different conversation, covered in the year-round guide, and keeping the two apart protects audit’s independence for when they test the fix.
What happens when audit tests your self-identified issue
Audit will test it, not because the label is doubted but because the report has to state the condition of the controls. What auditors test is lighter than for a finding they discovered, and more specific: they are confirming your record rather than building their own. Here is what we look at, in roughly the order we look at it, and what turns a self-identified issue back into an audit finding.
| What audit tests | Evidence requested | What makes it fail |
|---|---|---|
| Date of identification | The discovery email or ticket; the issue log entry with its system timestamp | The entry postdates the audit notification or the request for related evidence |
| Extent | Your population query and parameters; audit re-runs or re-performs it | Audit’s population is larger, longer or crosses into other systems; the difference becomes audit’s finding |
| Where else | Your analysis of similar controls, parameters, entities or products | You fixed the instance and never asked whether the cause touched anything else; audit finds the sibling |
| Cause | Your root cause analysis and the data behind it | The cause named is a symptom or a person; the fix will not prevent recurrence |
| Interim mitigation | Evidence it has operated every period since discovery | The daily review has gaps; the exposure was open longer than the record implies |
| Actions and dates | The plan, the owners’ agreement, progress to date | Dates set from hope rather than dependencies; an owner who has not agreed; silent revisions |
| Rating | Your proposed rating against the methodology definitions | Rated low to keep it quiet when the definitions say otherwise |
| Reporting | Who was told and when, including the second line and, where relevant, compliance | Audit was told; your executive, the second line or compliance were not |
| Closure evidence (later) | What you said you would show, shown; a period of operation for the new control | “Done” asserted without evidence; the fix has not yet operated through a cycle |
Four outcomes are possible. The issue is confirmed as management-identified and reported that way. The issue is confirmed but expanded: audit’s population is bigger, or a sibling control was affected, and the report credits your identification of the original instance while the extension is an audit finding; this is the most common way a good self-identified issue loses part of its credit, and the “where else” question is how you prevent it. The issue is re-rated, because the open exposure meets a higher definition than you proposed, which is a disagreement to have with the methodology open, as described in disputing a finding properly. Or the issue is converted: the record does not stand up, the actions have stalled, or the dates were quietly moved, and audit writes a finding whose cause includes the failure to act on a known problem; the right move then is a management response that records what you had already started, not an argument about the label. The validation at closure follows the usual evidence standards for issue closure, lighter in sample size but not in kind: a new control still has to have operated for a period before anyone calls it closed, and the owner’s guide to getting a finding closed lists what the validators will ask you to show.
Timing: planning, fieldwork or after
The timing rule is one sentence: tell them before they would have found it. The table below is practitioner judgment on where that line falls at each stage of the audit cycle and how functions tend to treat each case. The decisive moment is not the opening meeting; it is the first time audit touches the area, whether through a request list item, a walkthrough or a data pull. Before that, disclosure is self-identification. After it, disclosure is cooperation, which is still better than silence but earns a different sentence in the report.
| When you raise it | How it is usually treated | Consequences |
|---|---|---|
| No audit scheduled; raised through the log, the second line and a heads-up to audit | Self-identified, full credit; enters audit’s planning file | May reduce the scope of the next audit of your area or shift its timing; the issue is tracked to closure like any other |
| During the annual risk assessment interview | Self-identified; audit may plan a lighter review or a validation visit instead of a full engagement | Shows the function your area is self-aware; the interview is described in how audit plans choose what gets audited |
| At notification or in the planning calls for your audit | Self-identified if already logged; disclosed-at-planning if logged now | Audit adjusts scope: usually a validation of your record rather than discovery testing; the request list shrinks |
| At the opening meeting | Treated as a planning disclosure; the label depends on the log date | Audit will still test the extent; raising it here without a record reads as pre-emption |
| During fieldwork, before audit tests the area | Usually acknowledged as management-identified if logged the same day and raised with the lead auditor | The report credits the disclosure; the engagement rating effect depends on the methodology |
| During fieldwork, after audit has requested the evidence or walked the process | Audit’s finding; your disclosure noted as cooperation | The finding reads better than one where you argued, but the cause will note it was not previously identified |
| At the closing meeting or on the draft report | Audit’s finding; a claim of prior awareness without a record worsens the cause | “Management advised it was aware” is one of the worst sentences a report can contain about you; if you did log and act earlier, the draft review guide shows how to get the full sentence into the report |
| After the report, during follow-up | A new issue, logged as self-identified if the record supports it | Counts in your favor at the next audit; does not change the current report |
A practical corollary for anyone whose audit has just been announced: the two weeks between the notification letter and the request list are the last window in which a self-check costs little and pays fully. Walk the key controls, test five operations of each, and log what you find before the request list arrives. The week-by-week fieldwork guide shows how early audit’s data requests land; after the first data pull, the extent of a problem is in audit’s hands, not yours.
When self-identification backfires
It does, in specific and predictable ways, and every one of them is a failure of the record or the escalation rather than of the disclosure. The long-known, unfixed issue is the classic: a manager produces a three-year-old log entry as proof of self-identification and discovers that the entry proves the opposite, that the organization knew and did not act. The second classic is the issue that should have gone elsewhere first: a suspected fraud, a regulatory breach, a financial reporting error or customer harm, logged as an operational issue and worked quietly, when the first call should have been to compliance, legal or the fraud response protocol. In both cases the disclosure was right and everything before it was wrong.
| Situation | Why it backfires | What to do instead |
|---|---|---|
| A long-known issue, logged but not fixed | The record proves awareness without action; the cause becomes governance; the rating rises for duration | Either fix it with a real date and interim mitigation, or take it through formal risk acceptance; never let it sit |
| An issue that should have been escalated as fraud, a breach or customer harm | Working it as a routine issue delays mandatory steps, may breach notification duties and looks like containment | Compliance, legal or the fraud protocol first, the same day; log it afterward with their guidance |
| Relabeling an audit observation as self-identified | Audit has the walkthrough notes and the request dates; the attempt costs credibility on every other point | Accept the finding, respond well, and say in the response what you had already started |
| A vague entry with no population, cause or actions | It is a known issue in writing, which is worse than a known issue in conversation | Complete the template before logging; a day’s delay for a complete record is fine |
| Flooding the log with trivia | Dozens of minor self-identified items read as noise or as an attempt to look diligent; the real issue is lost | Log what meets your methodology’s issue threshold; handle the rest as routine corrections with a note in your own records |
| Fixing the instance, not the cause, and calling it closed | The sibling instance audit finds is an audit finding, and the closure looks premature | Ask “where else” before you log; include the sibling check in the record |
| Telling audit before your executive or the second line | Breaks the chain of command; the executive hears it from the chief audit executive | Executive first, same day; log and second line next; audit within the week |
| Self-identifying and then letting the dates slip silently | Age runs from the original date; the label does not survive the first missed deadline | Use the extension process, in writing, before the date, with what is done and what changed |
The cultural version of the backfire is worth naming. In some organizations the person who raises a problem becomes the person who owns the blame for it, and managers learn to stop looking. Audit functions can see this in the data: a business unit with no self-identified issues and a steady stream of audit findings is not a unit with no problems. If that is your environment, the record protects you more than silence does, because the finding will come regardless, and a dated entry showing you found it, escalated it and fixed it is the only version of the story in which you did your job. Edmondson’s work on psychological safety and Heffernan’s on willful blindness both describe how organizations drift into not-knowing; the issue log is the counterweight.
Building the routine: the quarterly self-check
Self-identification is a byproduct of looking, and looking has to be scheduled or it does not happen. If your organization runs a formal risk and control self-assessment, the RCSA is the vehicle: the quarterly attestation that each key control operated, with evidence, is where most well-run first lines find their own issues, and it is the “management’s self-assessment” that SR 13-1 expects internal audit to opine on. If it does not, the routine below is the same idea at the scale of one team, and it takes about half a day a quarter once the control list exists. It assumes you know your controls, which is the subject of control ownership; if nobody can name the key controls in your process, that is the first self-identified issue.
| Step | What you do | Output | Time |
|---|---|---|---|
| 1. Refresh the control list | Confirm each key control still exists, still has a named operator, and has not been changed by a system release, a reorganization or a departure since last quarter | Updated control list with change notes | 30 minutes |
| 2. Check the parameters | For every system-enforced control (thresholds, limits, approval routing, access roles), read the live configuration and compare it to policy | Screenshot or export per parameter, dated | 45 minutes |
| 3. Test five operations per control | Pick five recent instances of each manual control at random; check the evidence exists, is timely, and shows a review rather than a tick | A one-line result per control: pass, exception, or gap | 90 minutes |
| 4. Read the exceptions | Pull last quarter’s error logs, customer complaints, rejected items, overrides and late items; look for a pattern | A short list of recurring exceptions with counts | 30 minutes |
| 5. Review open actions | Every open action, audit or self-identified: on track, at risk, or needs an extension request now | Status update submitted to the log | 20 minutes |
| 6. Log what you found | Anything that meets the issue threshold goes through the template and into the log the same week; smaller items are fixed and noted | Issue records, or a dated note that nothing met the threshold | 30 to 60 minutes |
| 7. Tell the right people | Executive, second line, and a short note to your audit contact summarizing the quarter’s self-check and anything logged | One email, with the records attached | 15 minutes |
Step 2 catches more than its share, in my experience, because system parameters are changed by releases and vendor templates without anyone in the business being told, and because nobody reads a configuration screen unless a routine makes them. Step 3 is a scaled-down version of what audit does, and the point of five rather than twenty-five is that you will actually do it; the auditor-side guide to handling test exceptions explains why a single exception in five should make you pull more, not shrug. The note to audit in step 7 is where the credibility accrues: a manager who sends four of those a year is a manager audit stops worrying about.
When something does turn up and you call your audit contact, the words matter less than the record, but they still matter. The table gives the register that works and the register that undoes it.
| Moment | Say | Don’t say |
|---|---|---|
| Opening the conversation | “We found a control failure in our quarterly check on the 2nd. I have logged it, told my SVP and operational risk, and I wanted you to hear it from us. The record is attached.” | “Just a heads-up, probably nothing, but there might have been a small issue with wires.” |
| Describing the extent | “The full population is 1,284 wires over eleven weeks. We ran the query with IT on the 3rd; the parameters are in the record.” | “We think it was only a handful. We can look if you need us to.” |
| Describing the cause | “The change procedure did not require a post-upgrade check of control parameters. That is what we are fixing.” | “The analyst should have caught it. We have spoken to her.” |
| On the rating | “We have proposed Medium against the definitions, because the exposure closed on discovery and no loss occurred. Happy to walk through the reasoning.” | “It’s low, right? It’s fixed now.” |
| On what you want from audit | “Tell us if you want anything else for the planning file, and whether you want to see the new attestation when it runs in September.” | “Can you confirm this won’t be in the report?” |
| If audit already had the area under test | “Understood that this is your finding. Our record shows what we had started, and we would like that acknowledged in the response.” | “We identified this first, so it should be self-identified.” |
Worked example: Westbrook Savings Bank
Westbrook Savings Bank is a hypothetical regional bank; the names, numbers and dates are invented, and the mechanics apply to any organization with an issue log and an audit function. Dana Whitfield manages payments operations. On 14 March the bank’s core system is upgraded. The vendor’s configuration template resets the outbound wire dual-authorization threshold from the policy value of $25,000 to a default of $100,000. Nobody notices, because the change ticket required functional testing of wire processing and did not require a post-implementation check of control parameters. On 2 June a team lead investigating a customer query sees a $62,000 wire released by a single approver and raises it with Dana within the hour.
What Dana does over the next three weeks is the template above in motion; the timeline table carries the dates. The parameter is corrected the same afternoon and verified with a test wire, and a daily supervisor review of every wire above $25,000 starts the next morning as interim mitigation. IT’s population query on 3 June returns 1,284 wires between the two thresholds over eleven weeks; the issue goes into the GRC platform the same day with source “self-identified,” operational risk opens an event record, and Dana’s SVP has already been told. On 4 June Dana emails the audit manager who covers operations, record attached, noting that the payments audit is on the plan for the third quarter. The root cause is written as the gap in the change procedure, and the three actions from the template (the change-procedure checklist, the quarterly parameter attestation and the look-back of all 1,284 wires) are logged with owners and dates.
| Date | Event | Record created | Why it matters later |
|---|---|---|---|
| 14 March | Core upgrade; threshold reset by vendor template | Change ticket (no parameter check) | Becomes the root cause |
| 2 June, 11:10 | Team lead spots single-approver release; escalates to Dana | Email with the wire reference | Evidence of the discovery date and mechanism |
| 2 June, 15:40 | Parameter corrected and verified; SVP informed | Change record; test wire log; email to SVP | Exposure closed; chain of command intact |
| 3 June | Population query with IT; daily supervisor review starts; GRC entry; operational risk event record | Query parameters and output; review log; GRC issue with timestamp; event OR-2211 | Extent established by management; the dated entry that earns the label |
| 4 June | Email to internal audit with the record | Enters the planning file for the Q3 audit | |
| 20 June | Look-back of 1,284 wires complete: no unauthorized wires, three late callbacks | Look-back workbook with tick marks and reviewer sign-off | Impact quantified before audit asks; action 3 complete |
| 31 July | Change procedure updated with parameter checklist | Approved procedure, version and date | Action 1 complete with evidence |
| September | Payments audit fieldwork | Audit’s tests of the record | See below |
| 30 September | First quarterly parameter attestation | Attestation with screenshots | Action 2 complete; one operation, not yet sustained |
In September the audit team tests the record. The discovery date holds: the 2 June email and the 3 June GRC timestamp both precede the August notification letter. The population holds: audit re-runs the query and gets 1,284. The interim review log has no gaps. Then audit asks the “where else” question, and the answer hurts. Dana checked the wire threshold and nothing else. Audit reads the vendor template and finds that the same upgrade reset the ACH batch approval limit as well, which nobody had noticed because the daily ACH volume rarely approached it. The report therefore contains two items. In the section headed “Issues identified by management,” the wire threshold issue appears with status “actions 1 and 3 complete, action 2 in progress,” unrated under this function’s methodology. Among the rated findings, a Medium: the change management process did not verify control parameters after the upgrade, and a second parameter was also affected; the finding opens by acknowledging that management identified and remediated the wire instance and that the new checklist, once operating, addresses the cause. The engagement is rated Satisfactory. The audit committee pack shows one self-identified issue from operations and one Medium finding, both with owners and dates.
| Dimension | What happened (self-identified in June) | What would have happened (found by audit in September) |
|---|---|---|
| Condition in the report | 1,284 wires over eleven weeks, exposure closed 2 June | Roughly six months of single-approver wires, still open at the start of fieldwork, population established by audit |
| Cause | Change procedure lacked a parameter check | The same, plus no monitoring of a key fraud-prevention control for six months and no detection by management |
| Issue rating (practitioner judgment on a typical matrix) | Unrated, management-identified; the related change-management finding Medium | High: key control, long duration, undetected; the change-management cause folded into the same finding |
| Engagement rating (practitioner judgment) | Satisfactory | Needs Improvement under most aggregation rules, since a High usually caps the report |
| Action plan | Written by Dana in June, on her timeline | Written in the draft-report window, with audit’s recommendation driving it |
| Look-back | Done by June 20 on management’s initiative | Demanded by audit, possibly by compliance, under a deadline |
| Regulatory attribute if ever raised by examiners | Self-identified, found by the business | Still self-identified to the OCC if the bank disclosed it, because the bank’s own audit found it; inside the bank, an audit finding |
| Dana’s standing with audit | Improved; the one gap (where else) is a lesson, not a stain | Diminished; the next audit of her area arrives sooner and asks for more |
The lesson Dana takes from the sibling parameter is the one that generalizes: when the cause is a process failure, assume it produced more than one instance, and put the search for the others in the record before you send it. It costs an afternoon. The Medium finding cost a quarter of follow-up and a line in the committee pack that did not need to be there. This guide is general and educational; it is not legal or employment advice.
Questions readers ask
What is a self-identified issue in internal audit?
A control weakness, error or breach that management or its second-line functions found, documented with a population, cause, owner and dated actions, and logged in the issue system before internal audit, the external auditor or a regulator identified it. The term is not defined in the Global Internal Audit Standards; it comes from issue-management methodologies and supervisory manuals, so the exact criteria sit in your organization’s methodology.
Should I tell internal audit about a problem they have not found?
Yes, after you have told your own executive and logged it. A documented issue disclosed with a credible fix under way is reported as management-identified and, in most functions, excluded from the engagement rating or weighted lighter. The same issue found by audit after you knew about it is rated more severely, and the delay becomes part of the cause. The only wrong order is telling audit before your own management.
Do self-identified issues go in the audit report?
Usually, if they are relevant to the engagement’s objectives, because the report describes the condition of the controls and the issue is part of that condition. They appear labeled, either in a separate section for issues identified by management or inside a finding that credits your identification and progress. Standard 15.1 requires the final communication to acknowledge actions management has already started or completed.
Do self-identified issues affect the audit rating?
It depends on the methodology. Three common models are: reported separately and unrated; rated but excluded from the overall rating calculation; or rated and counted with the label shown. Under every model the issue’s own risk rating reflects the open exposure, and a self-identified issue whose actions go overdue loses the lighter treatment. Ask to see the rating definitions in your organization’s audit methodology.
What is the difference between self-identified and management-identified issues?
In most organizations they are the same thing under two labels: “self-identified” is the source value in the issue log, and “management-identified” is the phrase audit reports use. Some functions reserve “self-identified” for issues the first line found and “second-line-identified” for those found by compliance or risk testing; both count as found by the organization rather than by audit. “Self-reported” or “self-disclosed” usually refers to telling a regulator, which is a decision for compliance and legal.
Can an issue be self-identified if audit is already auditing my area?
Only if your record predates audit’s work in that part of the process, or if you raise it during fieldwork before audit has requested the related evidence or walked the related steps. If audit was already testing the area, the finding is audit’s, and logging it the morning after the walkthrough will be read as pre-emption. In that case accept the finding and put what you had already started into your management response.
Do regulators give credit for self-identified issues?
Several US bank and consumer-finance supervisory frameworks say so explicitly; outside those sectors, check your own regulator’s published position. The OCC’s MRA manual (PPM 5400-11, revised August 2026) requires each MRA to state whether the concern is self-identified and calls self-identification and remediation an important consideration in assessing corrective action, while noting it does not change whether a violation is substantive. The FFIEC consumer compliance rating system states that it provides incentives for self-identification and prompt correction, and the CFPB’s responsible business conduct bulletin lists self-assessing and self-reporting among the factors it weighs. Credit is for finding and fixing; the underlying obligation remains.
How do I document a self-identified issue?
Write it the way audit writes a finding, plus two fields: how and when you found it, and what you have already done. Title, condition with numbers, the requirement breached, discovery date and mechanism, population and extent, impact from a look-back, root cause, interim mitigation, corrective actions with owners and dates, evidence of completion, a proposed rating and who has been told. Enter it in the issue log, attach the evidence of discovery, and send the record to your executive, the second line and audit in that order.
Related guides
- Being Audited? hub — every stage of the audit from the auditee’s side, with quick answers.
- Living With Internal Audit Year-Round — the heads-up habit, the annual self-check and the evidence routine that make self-identification normal.
- Writing Management Action Plans That Actually Close — owners, dates, interim measures and evidence of completion for the actions in your record.
- Management Responses to Audit Findings: 15 Examples — complete responses by situation, including the issue you had already found and fixed before the report.
- Risk Acceptance by Management — what to do when the right answer to a self-identified issue is not to fix it.
- The Finding and Issue Log Template — the source field, the status rules and the lighter validation for self-identified items.
- How to Get an Audit Finding Closed — what validators test, the evidence pack by control frequency, and why “done” is not “closed”.
- Evidence Standards for Issue Closure — what proof of remediation requires, including for issues you raised yourself.
- Internal Audit Ratings Explained — finding and report ratings, aggregation rules, and how to read your methodology’s definitions before proposing a rating.
- Root Cause Analysis for Audit Findings, From the Auditee’s Side — a one-week method for a cause auditors will accept, and the non-causes they reject.
- Control Ownership — knowing your key controls is the precondition for finding your own issues.
- MRAs, MRIAs and Consent Orders Explained — how examiner findings escalate and where the self-identified attribute appears.
- SOX for Control Owners — what happens when the self-identified issue is in a key ICFR control.
- When You Disagree With an Internal Audit Finding — how to contest a rating or a label on the record.
Leave a Reply