Code audit severity levels: from low to critical
A normal code review grades quality. Ours grades legal weight. Code audit severity levels therefore tell a bank which findings could breach a banking rule and which are only notes. A tidy custom class can still be critical if it leaks client data. A messy class can be low if it touches none.
“Severity measures legal weight for banking data, not code quality, so a tidy class can still be critical.”
Our scale has four grades: low, medium, high and critical. A fifth grade, information, also records points that need no action. The bank’s counsel decides the final legal reading. We audit and advise, and we do not implement.
Code audit severity levels: low and medium
Low findings are small gaps in proof, with no client data at risk. An example is a Flow with no named owner or business purpose. Banks must be able to show what their automations do and who looks after them. Medium findings sit one step up. Examples are retention that the code does not enforce, or client data copied to a second field with no stated purpose. A medium finding does not expose data today. However, it makes a later breach more likely. The bank fixes these in its normal release cycle. Code audit severity levels keep that work in proportion.
High findings: a duty is probably at risk
Among custom code audit severity levels, high findings put a legal duty at risk. A common example is an Apex class in system mode that returns client records without checking the user’s access. Another is a send path with no consent check. A third is a trigger that writes personal data into a log in plain text. Because these flaws can breach the GDPR or a national rule, the bank should fix them before the next release. In the meantime, the bank can limit the code’s reach. A high finding is not yet a breach, but it is close.
Critical findings: stop, fix and call counsel
At the top of the custom code audit severity levels, critical findings are likely breaches now. Examples are passwords hard-coded in code and personal data sent to an unapproved endpoint. Another is a commercial message that goes out with no valid consent. A critical finding may start legal clocks. For example, the GDPR expects a data breach report to the authority within 72 hours. DORA also sets rules for reporting major ICT incidents. So a critical finding goes to the manager and to counsel on the day we find it. The bank should stop the affected release and fix the flaw first.
Using code audit severity levels in decisions
Using custom code audit severity levels in decisions is simple. Critical means stop and call counsel. High means fix before release. Medium means plan the fix. Low means tidy when convenient. Information means note it and move on. Each grade also combines how likely a rule is to break with the legal weight of the data involved. Code quality never changes the grade. The scale also works the same way in every report, whether for a manager, an architect or a developer. These time limits are our recommendation, and each bank can tune them to its own risk appetite.
