Cybersecurity Standards Framework

Security claims are only worth what they can be checked against. Gracker finds the official reference behind each claim, confirms it is real, and puts it where it belongs:

• On pages you already have. Every citation graded for whether it is real, linked, live and on-topic
• On pages you still need. The exact reference your competitor is already citing
• On pages Gracker writes. Woven inline, never invented

Cybersecurity brands only, detected automatically. Gracker classifies every brand the moment you add it. There is no switch to find. Security vendor? This starts appearing on your security content on its own. Not a security vendor? You will never see any of it.

Why this exists

Every security page makes claims:

• "Session tokens should rotate after login."
• "MFA prevents credential stuffing."
• "This flaw is being exploited right now."

Each one has an official source behind it: a published standard, a catalogued weakness, a documented attack technique. Someone at NIST or MITRE wrote it down and gave it an identifier.

Naming that identifier is the difference between a claim a reader can verify and one they take on faith. Answer engines treat it as a safety signal:

Most security content lands in the first row, and not through carelessness:

• Finding the correct reference is expert work: the right CVE, the right weakness class, the publication that genuinely backs the claim.
• It costs a security engineer 20-40 minutes per article.
• So security content queues behind engineering capacity. And when it gets rushed, a wrong or invented citation ships, then sits for months in front of exactly the readers you most need to convince.

Gracker does the lookup, guarantees every identifier it returns is real, and takes the job off one reviewer's calendar.

How it works, in one example

You publish a page: "Does single sign-on reduce phishing attacks?"

Gracker reads it, recognises it discusses an authentication control and a named attack technique, searches the official catalogues, and comes back with three references:

Your sentence goes from:

SSO reduces phishing risk.

to:

SSO reduces phishing risk, though session-cookie theft ( T1550.004 (opens in a new tab)) remains a live bypass, which is why NIST SP 1800-13 pairs SSO with phishing-resistant authenticators.

Same claim. Now checkable.

The six identifier types

Three organisations publish the identifiers security professionals treat as authoritative, across six id spaces. Each owns a different kind of fact.

These are not interchangeable, and reaching for the wrong one is a tell. An article about SQL injection as a concept should cite CWE-89, the weakness class. An article about one vendor's broken login should cite that vendor's CVE. A reader who knows the subject spots the difference immediately, and so does an assistant weighing whether to repeat you.

Gracker judges each id space separately, so what comes back is the kind of citation your content actually calls for, not whichever one happened to share a keyword with it.

What "verified" guarantees

Every identifier Gracker gives you was confirmed against the organisation that owns it. CVEs are resolved live against NIST's National Vulnerability Database. CWEs are resolved against MITRE's own CWE API. ATT&CK, CAPEC, the NIST publication list and CISA's KEV catalogue are matched against copies built directly from those organisations' published data. Anything that fails its lookup is dropped before it reaches you.

An AI decides whether a category of source applies to a page, and it may put a candidate forward - a product name worth searching for, or an identifier it believes fits. What it cannot do is make one count. Every candidate is looked up first, and a plausible-looking CVE-2029-99999 fails that lookup and never reaches a suggestion.

The URL is held to the same standard as the id. Every link points at the authority's own record page, not a summary, a mirror, or a blog that once described it.

The result is that a fabricated citation isn't something you catch in review. It's something that cannot reach the page.

In Page Audit

Standards checking runs whenever you audit a page that reads as substantive content: an article, a comparison, or an FAQ. Pricing, careers and feature pages are skipped, correctly.

What gets checked

Each authority the page touches is checked four ways, and a claim of active exploitation is checked against CISA on top of that.

How it scores

Twelve checks in total, and together they are your Trust Score, one of the four sub-scores behind Page Health.

Critical counts 5x, warning 2x, notice 1x, so an invented identifier costs far more than an unlinked mention. That ordering is deliberate: a missing hyperlink is untidy, a fake identifier is a credibility failure.

Checks that cannot apply are excluded from the maths entirely rather than counted against you.

When a page shows no score

A page with no security claims to check shows "Not a security topic" instead of a score. That is a verdict, not a gap. There was nothing for a catalogue to match against.

One case worth knowing. If your page names a real reference but never links it, Gracker does not offer you a different reference. It tells you to hyperlink the one you already have. You were right, you just left the reader no way to confirm it.

In Visibility Diagnosis

When Visibility Diagnosis works out why you aren't winning an AI answer, cybersecurity brands get references attached to the result.

Briefs and gap reports

The diagnosis hands back one of two things, and both arrive with references:

• a content brief. You have no page for this question, so here is what to write
• a gap report. You have a page, so here is what it is missing against the one beating you

Why a competitor's citation ranks first

This is the only place the engine reads a competitor's actual page. Every identifier sitting on it is pulled out and verified, and the ones that survive are ranked above everything else and labelled as competitor citations.

They answer a sharper question than what could I cite? They answer what is the page outranking me already citing?, which is a gap you can close on purpose rather than a research problem you have to open.

References the report's own fixes call for come next. Gracker's own search results come last.

In Content Generation

When Articles writes a piece for a cybersecurity brand, references are woven into the prose as real inline hyperlinks, each placed in the sentence that already discusses that idea, never collected into a list at the bottom.

What you can expect

• Citations sit inline, in the sentence that already discusses them, never collected into a "References" list at the bottom.
• Every link points at the official record page, so a reader can check the claim in one click.
• Nothing is said about a reference that wasn't verified - no severity scores, dates or product names appear unless they came from the source itself.
• Only vulnerabilities confirmed as actively exploited are described that way.
• The rest of your article is left alone. Structure, headings, brand mentions and existing links all stay as written.

If anything goes wrong along the way, your article is left exactly as it was rather than half-edited.

Articles generated from a diagnosis

An article generated from a diagnosis inherits that diagnosis's references exactly. It does not go looking again. What you accepted in the brief is what gets written in, with no drift between the plan and the article. Generate outside a diagnosis and Gracker discovers references from the finished draft instead.

How a reference is chosen

The three passes

Not required reading. It is here because it explains why the output can be trusted.

PASS 01

Does this need a citation?

Reads the page and decides whether NIST, MITRE or CISA are in play at all. Produces no identifiers, which is why a security company's pricing page comes back empty.

PASS 02

What is already cited?

Pulls every identifier out of the content and checks it against the real catalogue. Fakes are discarded. A confirmed one can switch a source on, never off.

PASS 03

Find the reference

Only now does Gracker search, and only in the catalogues the first two passes pointed at.

In Visibility Diagnosis, where a competitor's page is in front of us, pass 2 outranks pass 1: if the reading pass says "no MITRE citation needed" while a real, verified CVE sits on the competitor's page, the evidence wins. Judgment can miss things. A confirmed identifier cannot be argued with.

Where each type comes from

In Visibility Diagnosis, meaning-based matches must also clear a relevance floor: a weak match is dropped rather than shown, on the principle that a suggestion you never see costs you less than a wrong one you act on.

Why a reference was suggested

Every suggestion carries a plain reason, so you can judge it without opening anything.

How many you get

At most 2 NIST publications, up to 4 MITRE references (one CVE, one CWE, one CAPEC, one ATT&CK) and at most 2 CISA entries. Fewer whenever fewer genuinely fit. None at all is a legitimate answer, and a common one.

When nothing appears

Deliberately narrow. Security citations on non-security content are noise, and noise costs more credibility than silence.

FAQ

How do I turn this on?

You don't. Gracker classifies each brand as cybersecurity or not the moment you add it, reading its name, domain, industry, description and the prompts you track. If the verdict is yes, Page Audit, Visibility Diagnosis and Articles all start including standards work on that brand's security content automatically. There is no setting to flip.
See Brand Management.

What decides that my brand counts as cybersecurity?

Whether security is the core business, not whether security gets mentioned. Vendors of network, endpoint, cloud and application security, SIEM/SOAR/EDR/XDR/MDR, firewalls, threat intelligence, vulnerability management, penetration testing, IAM/PAM/SSO/MFA, zero-trust, DLP, encryption and PKI, security GRC, fraud and bot detection, DDoS protection and security awareness training all qualify. General IT and devops, observability, cloud hosting, data and analytics do not, even though all of them touch security. Payments is the one with a caveat: a fintech qualifies if the product itself is fraud or security, not if it merely moves money securely. If security is a feature of what you sell rather than the thing you sell, the answer is no.

My brand was classified wrong. Can that be corrected?

Yes. Contact support and it can be changed on our side. Classification runs once, when the brand is created, so the usual cause is a brand added before its positioning was filled in, or one whose description is vague about what it actually sells. A brand that couldn't be classified at all is left unclassified, and unclassified behaves exactly like "not cybersecurity": nothing runs.

My security page shows no Trust Score. Why?

Trust Score only appears where it is relevant: the page has to read as an article, comparison or FAQ, and it has to make security claims worth checking. Homepages never qualify, and Product or Service structured data outranks Article, so a comparison page carrying product schema is skipped. Adding JSON-LD declaring the page an Article is the usual fix. See Trust Score.

It says "Not a security topic" on a page that is obviously about security.

That verdict means no authority applies to the specific claims being made, which nearly always means the page stays at the category level - "misconfigurations", "weak permissions", "best practices" - without naming a specific weakness, technique, control or product. There is nothing concrete for a catalogue to match against. Naming the specific thing is both better writing and what makes a citation possible at all.

Can I publish these citations without checking them?

For existence and for the link, yes: every identifier was confirmed against the authority's own catalogue, and every URL points at that authority's record page. Relevance is a strong match rather than a guarantee, so whether a reference fits the argument you're making is still your call. That last judgment is deliberately left with you.

My Trust Score is low but every citation on the page is real. What's wrong?

Real is one of four checks. The others ask whether the source is actually hyperlinked, whether that link still resolves, and whether the citation is on-topic for the claim beside it. Naming NIST in a sentence with no link, or putting a real advisory next to an unrelated claim, both cost you - and a page can fail all three while every identifier on it is genuine.

Is a claim of active exploitation checked?

Yes, and it carries critical weight. If your page says a vulnerability is being exploited in the wild, that CVE is checked against CISA's Known Exploited Vulnerabilities catalogue. "Could be exploited" or "is exploitable" is a different claim and isn't judged this way - only an assertion of ongoing, real-world attack is.

Why two NIST publications instead of one?

So you have a choice. Topics often sit across two publications, and the second is sometimes the better fit for your particular angle. You're meant to pick one, not cite both.

Why did it suggest one vendor's CVE for my general article?

Usually because that CVE is the landmark case for the technique you're describing, or because a competitor cited it. If it genuinely doesn't fit, skip it - the CWE in the same set is normally the better citation for a conceptual piece, which is exactly why the two types are offered separately rather than as one "best" answer.

Will it duplicate a CVE that's already in my article?

No. If that CVE is on the verified list, the mention you already have becomes a single inline hyperlink rather than a second copy appearing further down. If it isn't on the list, it still gets linked to its official NVD record - but nothing is claimed about it, because its severity, date and affected product were never verified.

What about a CWE, CAPEC or ATT&CK id in my article that isn't on the verified list?

It stays exactly as you wrote it, as plain text. It won't be hyperlinked and nothing will be asserted about it. CVE is the exception only because a valid URL can be built from the id alone; the other catalogues have no such rule, so Gracker leaves them untouched rather than guessing at a link.

Will the article I generate use the same references I saw in the brief?

Yes, if you generate it from that diagnosis. The article inherits the diagnosis's verified references directly and skips re-discovery, so there's no drift between the brief you accepted and the piece that gets written. Generate an article outside a diagnosis and Gracker discovers references from the draft itself instead.

The diagnosis found no references. Will generation look again?

No. An empty result means the diagnosis looked and concluded nothing applies, and that verdict is respected - the article is written without references rather than second-guessed with a fresh search.

Will it add a "References" section to the bottom of my article?

No, and it's explicitly forbidden to. Every citation goes inline, in the sentence that already discusses that idea. A reference list at the bottom is easy to write and just as easy for a reader - and an answer engine - to ignore.

What happens if a lookup fails or a catalogue is unreachable?

It fails quiet, never loud. An identifier that can't be confirmed is dropped rather than shown unverified, a diagnosis carries on without its standards section, and an article that hits an error mid-pass ships with its original text intact. Nothing unverified is ever shown as a fallback.