Methodology

How every number on this site is produced

If we cannot explain how a figure was derived, we do not publish it.

Sourcing

Roles come from employer career pages and publicly accessible listings only. Nothing behind a login, paywall, or an explicit no-scraping term is collected. Each role records where it came from, when it was first seen, and when it was last verified against the source.

Title normalization

Employers use the same words for very different jobs. Each role is mapped to a normalized level — CISO, Deputy CISO, VP, Head, or Director — based on reporting line, team size, budget ownership and stated scope, not on the words in the title. The employer's original title is always shown alongside so you can see the mapping.

Compensation

  • Disclosed: the employer published a range. It is shown as stated, labelled disclosed.
  • Estimated: derived from comparable roles by level, industry, company size and location. Labelled estimated, with a confidence level and sample size.
  • Insufficient data: fewer than five comparable roles. No estimate is shown and no market label is applied.

Market labels compare the midpoint of a role against comparable roles. Where the sample is too small to be meaningful, the label reads “Insufficient data” rather than defaulting to “At market”.

CLI Career Level

Every role is read onto one ladder — Manager, Senior Manager, Director, Senior Director, VP, Deputy CISO, SVP, CISO, Enterprise CISO — so that titles from different employers can be compared. The read starts from a title baseline and is then moved by evidence found in the posting: the stated reporting line, budget ownership, team size, functional and geographic scope, board or regulator exposure, and the scale of the employer. Every signal that moved the level is shown on the role page with the wording it came from, and each level carries a confidence band reflecting how much of that evidence the posting actually contained. Where a role is reviewed by hand, the staff read replaces the computed one and is marked verified.

Opportunity Score

The Opportunity Score is a 0–100 read of the role itself, not of you. It is a weighted blend of compensation against comparable roles, reporting level, functional and geographic scope, quality of the mandate, budget and team authority, executive and board exposure, employer trajectory, and how much the posting actually discloses. Each component is shown with its score, its weight and the sentence in the posting that produced it. Absent evidence lowers confidence rather than silently lowering the score, so a thin posting reads as low confidence instead of as a bad role.

Executive Fit

Executive Fit is the only figure that depends on your profile, and it is never shown to employers. It is rule-based and deterministic — there is no opaque model. Each dimension produces a score and a written reason, including career trajectory, which compares the CLI Career Level of the role with the level and timeline you have recorded as your next move. The weights are fixed and published here:

  • Leadership scope and seniority20%
  • Career trajectory and stated target10%
  • Security domains16%
  • Industry and regulatory experience13%
  • Company scale and stage8%
  • Location and work mode10%
  • Compensation10%
  • Board and public-company experience8%
  • Required credentials or clearance5%

Hard constraints — compensation floor, work authorization, clearance and excluded employers — are reported separately rather than silently reducing a score. Protected characteristics, and proxies for them such as graduation year or name, are never inputs.

Hiring path inference

Where a posting names a hiring manager, it is marked stated. Where a likely sponsor is inferred from public organizational information, it is marked inferred, given a confidence level, and shown with the reasoning behind it. You are always told which is which.

Review and correction

Roles are reviewed before publication, and any role can be flagged as closed, stale, or inaccurate. Corrections are applied to the source record so the change persists across future refreshes rather than being patched on the page.