Writing Cybersecurity Job Descriptions That Aren't Like Bad Tinder Profiles: A Guide for Employers

With the notable exception of bathroom selfies, most people don't post unflattering pics on their online dating profile.  They put at least a little bit of effort into finding a few good pictures, write something about themselves that’s catchy and intriguing, and give some thought to how to make themselves look presentable, in a simple manner. And the good ones provide a polished but realistic view of the themselves- after all, if the pics are fake, you are certainly going to know on that first date.

Job descriptions serve a broader purpose than just enticing candidates, but nevertheless, they are often the first glimpse that a potential employee has. Those first impressions matter. And, in many if not most cases, they are pretty awful.

In addition to those first impressions, job descriptions form the basis for any number of HR activities such as compensation benchmarking, performance management, and recruiter sourcing outreach, and also set expectations for the candidate about what the work is that they will actually be doing.

Despite this importance, the effort and thought that tends to go into them is often nil. Most JDs are written as if they came out of ML technology from 2012, trained on utter corporate gobbledygook. Heavy on buzzwords, light on coherence.

Cut and paste is the operative phrase. New JDs are Frankensteined out of existing ones.  People google something similar and just take whatever they find. HR departments take the lead and stuff all the corporate jargon in that the words become meaningless. It all serves as a convenient replacement for taking the time to think deeply about the job to be done, the true requirements to be successful, and then putting pen to paper in a thoughtful, clear, and concise manner that a reader will understand.

We will share a few common patterns that we commonly see in our industry, and offer advice on what to do instead.

Pattern 1: The Founder

Many JDs in our industry tend to feature outrageous expectations in terms of number of years of experience, particularly with technologies that, frankly, are not all that old.

Here’s a great one for an IAM administrator with pay less than $80K per year:

• 7 years of information security experience
• 8 years of Okta experience

Okay, wait.  First off, the math doesn’t even work. Secondly, 8 years ago Okta was only about 4 years old and their sales were ~3% of what they are today. Really? If you want someone with that much Okta experience, may I direct you to Todd McKinnon (but I’m guessing he will cost a bit more than $80K).

More broadly, there is widespread ignorance of market compensation rates aligned to years of experience. Even in companies I’ve been around that only do cyber, frequently HR departments will use general IT benchmark data from Mercer and the like, which does not accurately reflect real compensation in the market. Trust me, if even cyber companies struggle to get this right, many companies where cyber is only a department will struggle even more. So the jobs sit there, unfilled, and without any applicants.

Pattern 2: The Unicorn

This one is a lot like the founder, but with a bunch of requirements all stacked together. 

From a real job description:

• 10+ experience in Ping Federate / Ping Access
• 10+ years experience scripting in Python
• 10+ experience in SailPoint IAM
• 2-3 years in relevant SailPoint development and automation
• 2-3 years in Privileged Identity Manager preferably Thycotic Secret Server
• Technical Skills: ForgeRock OpenAM, Transmit Security MFA, Oracle Identity Governance, Transmit Security

Oftentimes, job descriptions will simply stack a bunch of wishes together, call them requirements, and give little thought as to whether that specific combination of experiences and expertise can be present in the same human being. Roles that require people to wear more hats (often, in companies with smaller security teams) need to have less stringent qualifications for several specific areas of expertise.

Pattern 3: The Incoherent Incredible Communicator

This is one of my favorites (from a big bank, to remain nameless):

• Requirement: Effective Communications – Understanding of effective communication concepts, tools and techniques; ability to effectively transmit, receive, and accurately interpret ideas, information, and needs through the application of appropriate communication behaviors.

Who speaks like this?  I surely don’t want to work for them.

Maybe the best way to get a job here is to hire an android and have it do your interview for you.  That would be an excellent most cognitively superior and appropriate strategic decision making process.

Pattern 4: The Secret Decoder Ring

Many companies are heavy on unique nomenclature and acronyms (we’re also looking at you, government). These things can be indecipherable to outsiders. And using acronyms and words that only make sense to insiders is no way to get any outsider to want to work with you. Check out this one (SIC):

• Assist in Onboard SAP for app and infra to ACAT (complete classification, collect SOD rules, map requestable roles) and work with AO to classify and complete review steps including documenting issues and collecting remediation.

I’m sure this sentence makes sense to people that are niche IAM experts for ERP systems or those that are familiar with this particular company, but for most people (including many potential candidates) this just looks sloppy and insular. Even normal words like ‘applications’ and ‘infrastructure’ aren’t spelled out, and others are misspelled.

I’m just going to assume that ACAT means this.

Pattern 5: The Mystery

The opposite of the unicorn, sometimes we have jobs that are so tersely worded and vague that it’s hard to know what we are really talking about.

Take this one for instance (this is the whole job description, also SIC):
·  Good in IAM process
·  IAM Function testing
·  Experience in any IAM tools

I bet they had a flood of applications for that one!

Pattern 6: The Scholar

It’s common for most job descriptions (in and out of cyber) to have an educational requirement. Usually, this is a quick proxy for knowledge. However, in cybersecurity- it simply isn’t. This industry changes so fast, and learning through hands on experience is so critical, that educational background, honestly, is largely irrelevant when it comes to predicting job performance.

Yet, the vast majority of cybersecurity JDs still maintain a degree requirement (often in IT), and many maintain the convention of assuming that higher orders of education equate to more relevant knowledge. Check out this JD for a generalist solution architect role:

• Requires a minimum of 8 years of related experience with a bachelor’s degree; or 6 years and a master’s degree; or a PhD with 3 years of experience; or equivalent work experience

I understand the value of a PhD if you are working on advanced encryption technology, or quantum computing, or advanced nation state threat adversary research. However, if you are generalist security architect, breadth is your friend. PhD programs are not designed with that in mind. Much better to actually define what someone should specifically know for this job, than assume any of that knowledge would have been transmitted through a bachelors, masters, or PhD degree.

Try this instead

Alright, enough complaining and snark.  I promised commentary on what to do.  Hopefully obvious and simple (but I know, not always easy):

• Actually invest some time and brainpower
• Say what the work to be done actually is
• Say who the hiring company is and highlight what makes them different.  Please don’t lie— experience should match the promise
• Use commonly accepted industry terms for what a job is, and what a thing is.  You aren’t all that unique.
• Be thoughtful in defining what specifically must be known coming in vs. what can be learned on the job
• Use good data sources for compensation that understand cyber
• Use language that real human beings use
• State a real compensation range upfront.  Be transparent.
• Be concise

If you have egregious examples, thoughts, ideas- send them my way. I'm always collecting examples… the good, the bad, and yes, even, the ugly.

‍