An observation is one security finding in your register: something you noticed, what it puts at risk, and what to do about it. The trick to SecurityTrackr is that you don't have to write it up formally. You describe what you found in plain words, the AI drafts the structured finding, and you review and save. Here's the whole flow, the handful of things that make an observation good, and the few that make it useless.
What you're actually creating
Everything in SecurityTrackr hangs off observations. One observation is one finding in your register. It carries a title and summary, a risk rating, a mapping to ISO 27002 and NIST CSF, a list of recommendations, and a treatment decision once you've triaged it.
Hold on to that “one finding” rule, because it's the thing most people get wrong on day one. A risk rating and a treatment decision only mean something when they point at a single issue. Ten issues crammed into one observation can't share one rating.
First, set up your organisation
Observations belong to your organisation, and there's only one: yours. Every observation attaches to it automatically, so there's nothing to pick and no client list to keep. The one job up front is to fill in your organisation profile. If it isn't done, the app says so straight: “Go to Account → Organisation and complete your organisation profile first.” Sort that once and you're ready to log findings.
Making your first one
Three steps: you write, the AI drafts, you review. The middle one is the AI's; the first and last are yours.
Step 1: say what you found
Open New observation. The only field that matters is the one at the top, Your Observation. Write what you saw the way you'd say it to a colleague:
The VPN allows passwords as short as 4 characters with no complexity requirements. We observed that several accounts use weak passwords that could be brute-forced.
That single note is the minimum. Everything else on the form is optional and exists to make the draft sharper. If you have the context, spend two minutes on it:
- Affected systems / assets. List hostnames and IPs, with environment labels. e.g. FortiGate VPN Gateway (192.168.1.1), Azure AD (Production).
- Existing mitigating controls. Controls already in place, not planned ones. The AI factors them into the risk call. e.g. VPN only reachable from the corporate network, MFA enforced.
Step 2: let the AI draft it
Hit generate and the model turns your note into a structured finding: a formal title, a summary covering what, where and why, a likelihood and impact call, recommendations, ISO and NIST mappings, and a set of search keywords. It also pulls any existing controls you mentioned (anywhere in your text, not just the controls field) into their own list.
Step 3: review, then save
Nothing's saved yet, and every field is editable. Read the summary, sanity-check the risk call, trim or add recommendations, adjust the ISO areas. If the finding looks like one you've logged before, a duplicate warning flags it during review so you don't end up with two of the same thing.
What makes a good one
The AI handles the formal write-up. Your job is to feed it something accurate and specific. The difference between a sharp finding and a vague one is all in what you put in.
| Be concrete. | Name the system, the version, the setting, exactly what you saw. Specifics give the AI something to work with. |
| One finding per observation. | So the risk rating and treatment decision actually mean something. Split a multi-issue note into separate observations. |
| Note controls already in place. | They change the risk. The AI reads them straight out of your text. |
| Don't paste a whole scanner dump in. | Split it, or use the dedicated import tools for bulk findings. One observation is one issue. |
| Don't be vague. | “Security needs improving” gives the model nothing. Say what's wrong and where. |
| Don't list missing or planned controls as existing ones. | That field is for what's deployed today. Planned work belongs in recommendations. |
| Don't paste live secrets or credentials. | Describe them, don't reproduce them. Fields are encrypted at rest, but there's no reason to store a working key. |
None of this needs to be polished prose. Get the facts right, name the systems, and let the draft do the formatting. The one thing worth a second look every time is the risk rating: the AI proposes it, but you own it.
What happens to it next
A fresh observation lands in Awaiting Triage. From there you make one call: mitigate or accept.
- Mitigate. Work the recommendations. Each moves Open, then In Progress, then Completed (or Won't Do). The observation reads Mitigating until they're all closed out, then Mitigated.
- Accept. Record why you're living with the risk. The justification is required, and stored encrypted. The observation reads Risk Accepted.
You never set the status directly; it's derived from your treatment decision and the state of the recommendations. Along the way you can assign an owner, attach evidence, and drop comments as the work moves.
Wondering how the AI picked Critical over High, or where likelihood and impact come from? That's the next article: how risk scoring works.
Your first-observation checklist
- Fill in your organisation profile so your observations have somewhere to land.
- Open New observation and describe one finding in plain words.
- Add affected systems and existing controls if you have them.
- Generate the draft, then read every field before you save.
- Heed the duplicate warning if one shows up.
- Triage it: mitigate and track the fixes, or accept it with a documented reason.