Honestly, this one tripped me up for a solid month when we first rolled out AuditBoard. The way some people talk about it, you'd think the difference is profound and earth-shattering. It's not. It's mostly about scope and workflow stage.
Think of it this way: a **Finding** is the raw observation. It's the "what." You found a control that's missing, a test that failed, a document that wasn't signed. It's a discrete piece of evidence that something isn't right. In AuditBoard, you're typically logging these during testing. It's your collector's bucket for problems.
An **Issue** is the "so what" that gets managed. It's the formal, approved container for one or more related Findings that the business has acknowledged needs to be fixed. The Issue is what gets assigned an owner, a due date, tracked through remediation, and reported up to management. If a Finding is a symptom, the Issue is the diagnosed condition you're actually treating.
The real confusion comes because in small audits, one failed test (a Finding) often *is* the whole problem, so it becomes a one-to-one mapping to an Issue. Then people use the terms interchangeably and new folks get lost. The platform itself can feel a bit bureaucratic here, but the distinction is useful when you have a mess of related control failures that all stem from one root cause. You just bundle them under a single Issue to avoid micromanaging fifty tiny fixes.
So yeah, it's a lifecycle thing. Finding = identified. Issue = formally tracked for resolution. Not magic, just process 😉
Another tool isn't the answer.
Spot on with the workflow stage analogy. That one-to-one mapping in small audits is exactly what trips up our team, too. We started calling Findings "field notes" in training, which helped folks stop treating every single note as a ticket that *must* become an Issue.
Where it gets fun is when you use integrations. You can sometimes push a Finding to a ticketing system like Jira as a subtask, and then the parent Jira ticket becomes the official Issue in AuditBoard. That visual really drives home the container concept.
Integrations are my jam.
Love the "field notes" analogy, that's perfect for getting teams out of the one-to-one mindset. The Jira integration example is exactly where this clicks for people.
A practical caveat we've hit: sometimes that "parent ticket" becomes an Issue with *multiple* Findings attached, which is great. But you have to watch out for scope creep. I've seen a single Jira ticket get linked to Findings from three different audit areas because the root cause was similar, which made the remediation tracking a bit of a mess. It forced us to be stricter about defining what constitutes a "related" Finding before we bundle.
The visual shift from a list of Findings to a single tracked Issue really does solidify the whole lifecycle.
test the migration twice
Your symptom-versus-diagnosis analogy is the most useful framing I've seen. It maps directly to the data hierarchy you'd track in any observability system. A Finding is an individual log line or an anomalous metric datapoint - it's signal, often noisy. The Issue is the declared incident or the created alert rule, the structured entity you manage through a lifecycle.
The one-to-one mapping problem in small audits mirrors a common anti-pattern in monitoring, where teams treat every single alert firing as a unique incident instead of grouping related symptoms. It creates massive overhead and obscures the root cause. The discipline in AuditBoard to group related Findings into a managed Issue is the same discipline required to create meaningful, actionable alerts instead of noise.
That workflow stage separation - collection versus management - is why the distinction matters for scale. You can't efficiently manage remediation if your tracking system is just a flat list of raw observations.
metrics over vibes
The observability analogy is a stretch. It's a symptom of vendors overcomplicating simple concepts to sell more training.
>group related Findings into a managed Issue is the same discipline required to create meaningful, actionable alerts
In theory. In practice, the main driver for grouping is appeasing management who don't want a long finding list. It's political, not analytical.
That "discipline" just creates another layer of debate about what's related. Now you're spending more time justifying the grouping than fixing the actual problems.
Just saying.