Findings

• A title in plain language, its severity and the area it belongs to (email, website, domain…).
• What's going on and what to do, written for whoever has to decide, not only for technicians.
• The detailed explanation: what it means, what could happen to your company, how an attacker would take advantage of it (as a short story, never as a manual), the steps to fix it (for your provider when Ward recognizes it), how to check it's fixed and who should do it.
• The technical detail: the evidence Ward saw, so whoever fixes it can confirm it.
• A button to ask Ward AI about that specific finding, and a history with comments and attachments.

Read it from top to bottom; each part answers one question:

• Title and severity: what it is and how urgent. Start with the most severe.
• What's going on and what to do: enough to decide. If it's not yours to fix, the explanation says who it is.
• Technical detail: the evidence, exactly what Ward saw. It's what you hand to whoever fixes it, and what you look at again afterwards.

Reading the evidence

The evidence is a literal value anyone can see from outside: a DNS record, a response header, an address and port. Ward shows it so you can check it. These are three real kinds, with sample data:

To confirm a fix, look at the same value again: if it changed, Ward will close the finding on its next check. If the evidence doesn't look like anything you recognize, that is useful too: ask your provider what it is before accepting or dismissing it.

Severity tells you how urgent a finding is. It also decides how much it lowers your Ward Score and whether you get an instant alert. It is Ward's assessment of the problem in general: if it matters less in your business, don't ignore it, accept it with a note.

Critical

An attacker can take advantage of it now, with serious damage. Act today.

High

A serious risk that makes an attack easier. Fix it this week.

Medium

A real weakness, but one that requires more from an attacker or has limited impact. Plan it.

Low

Good practice with little direct impact. When you have time.

Info

Useful context with no risk of its own. It doesn't lower your Ward Score.

Each finding has a status that you choose from the finding itself (or for several at once from the list). It says who's dealing with it and whether it counts against your Ward Score. This is how a finding moves between them:

Open

Still counts against your Ward Score and sends alerts.Nobody has decided anything yet. Don't leave findings here for weeks: choose one of the others.

In progress

Someone is working on it. Still counts against your Ward Score.Someone has been assigned and has started. It keeps counting and alerting: it's a signal for your team, not a pause.

Planned fix

You've scheduled the fix. No alerts and it doesn't count until the date; if it's still there after that, it counts again.You know how you'll fix it, but not now: a renewal, a provider change, a maintenance window. Pick a date up to 180 days ahead and write a note. If it's still there after the date, it counts again.

Pending verification

You say it's fixed. We'll re-check and confirm.You've fixed it. Ward checks it again: if it's gone, it's resolved; if it's still there, or it couldn't be checked, it goes back to Open and the history says why.

Resolved

Verified as fixed by Ward. It no longer counts against your Ward Score.You can't choose it: only Ward sets it, after checking.

Accepted risk

You've accepted this risk. It no longer counts against your Ward Score or sends alerts. A note is required.The problem is real but you choose to live with it (a legacy system you can't change, a cost that isn't worth it). A note of at least 5 characters is required, and you can set a review date: when it passes, it counts again.

False positive

Not a real problem. It no longer counts against your Ward Score or sends alerts. A note is required.Ward points at something that isn't a problem for you, for example a service you've confirmed is meant to be public. Explain why in the note so whoever comes next understands.

When in doubt, answer in this order:

• It isn't a real problem in your case? False positive.
• Is it already fixed? Pending verification.
• Is someone fixing it now? In progress.
• Will you fix it later, on a date you know? Planned.
• Have you decided not to fix it? Accepted, with a review date.

1. 1

   Read it and decide who does it

   The explanation tells you whether it's something for you, your IT person or your provider. You can copy the instructions to send them.
2. 2

   Mark it “In progress” or plan it

   So your team knows it's being handled. If it will take a while, plan it with a date: it stops counting until then.
3. 3

   Fix it

   Follow the steps. If you're unsure, ask Ward AI from the finding.
4. 4

   Mark it “Pending verification” or press “Check now”

   Ward re-runs only the checks for that finding. Only Ward marks it as resolved, so you know it's really fixed. Some sources can take days to show a change, and the button warns you when that happens.

“Check now” runs the same passive checks that produced the finding, without waiting for the next scheduled scan. The result:

• If it's gone, it becomes Resolved.
• If it's still there, it goes back to Open with the time of the check.
• If the source didn't answer, nothing changes.
• You can also start it when you mark the finding as fixed.

• The same finding can be checked again every 5 minutes.
• Up to 20 checks an hour per organization.
• Some sources, such as Shodan or the blocklists, can take days to show a change. The button warns you when that's the case.

• Every finding gets a reference such as W-014 that never changes or gets reused, even if the problem disappears and comes back. Use it in emails or with your provider. You can turn references off in Settings.
• Findings that share a cause appear grouped (for example, all the vulnerabilities of one product on one address, or all the lookalike domains). A group counts as a single finding for the Ward Score: the worst one.