Last updated: September 3, 2026
By Jennifer Burdick, Recruiting Manager, KORE1
A cloud security engineer job description should state who owns the fix, not just who finds the problem. That one line decides your candidate pool, your pay band, and whether the req closes in six weeks or six months.
Fourteen years recruiting, thirteen of them at KORE1, and cloud security is still the desk where I see the widest gap between what a posting says and what the team actually wants. Not by a little. The two candidates who reach your final round are often doing different jobs, and the posting is why.
A health-tech company in Austin ran a cloud security engineer req for eleven weeks last year before it came to us. The posting looked fine. Identify and remediate misconfigurations across AWS and Azure, partner with engineering, support SOC 2. Two finalists came out of that stretch. One had spent four years inside a managed security provider, lived in Wiz and AWS Security Hub, was genuinely sharp on findings triage, and had never opened a Terraform module. The other wrote Terraform daily, maintained a module library, and had never once sat across a table from an auditor.
The hiring manager liked both. The posting had promised both.
Nobody had asked the question that settles it, which is whether this seat would have merge rights on the infrastructure repo. Once we asked, the answer took about nine seconds. No. Platform engineering owned that pipeline, had owned it for three years, and was not handing it over to a new security hire. So the job was the first candidate. It had always been the first candidate. Eleven weeks and one declined offer to learn something a twenty-minute intake call answers in week zero.
Read the rest knowing who wrote it. I run cloud security desks at KORE1 and we get paid when somebody signs, which gives me a quiet incentive to want your search to stay hard. The template below is free, nothing here is gated, and most teams who fix the boundary language close the req on their own. I would rather you do that than call me and stay stuck.
The Three Lines a Cloud Security Job Description Has to Draw
A security engineer job description can get away with being loose about scope, because in most on-prem shops the person who finds the problem and the person who fixes it report to the same director. Cloud does not work that way. The work sits on top of a provider’s infrastructure, inside a platform team’s deployment pipeline, next to somebody else’s on-call rotation. A candidate reading your posting is trying to work out which of those three rooms they are being hired into.
Name all three and your applicant pool sorts itself before it reaches you. Leave them out and you do that sorting by hand, in interviews, one candidate at a time, for six weeks.
Line One, the Provider Boundary
Everybody nods at shared responsibility and then writes a posting that ignores it. Your provider secures the hypervisor, the physical plane, the managed control plane. Your company configures everything above that, and configuration is where the incidents live. This is not a vendor talking point. CISA put it in writing. Binding Operational Directive 25-01 landed in December 2024. It gave federal agencies deadlines to assess and fix their own cloud tenant configurations, and the reason it gives is blunt. Bad configuration of security controls in cloud environments had introduced substantial risk and produced real compromises. Their tenants. Their problem. The provider was never going to do it for them.
A senior candidate is scanning your posting for evidence that you know this. One sentence does it.
Line Two, the Platform Boundary, and the One That Decides the Hire
Here is the question nobody puts in writing. When your cloud security engineer finds a public S3 bucket, an over-permissive Azure role assignment, or a GCP service account holding owner on the project, what happens next?
Three honest answers exist. They are three different jobs at three different price points.
| Model | What the seat actually does | Who you are hiring | Posting language that works |
|---|---|---|---|
| Detect and hand off | Tunes CSPM policy, triages findings, writes the ticket, chases it to closed | Security operations background, tool depth, relentless written follow-through | “You will own findings from detection through verified remediation by the owning team” |
| Detect and fix | Opens the pull request against the Terraform repo and gets it merged | Engineer who codes daily, reads other people’s modules, survives code review | “You will have write access to our infrastructure repositories and ship the fix yourself” |
| Build the guardrail | Writes policy-as-code so the misconfiguration cannot be deployed at all | Platform-security hybrid, comfortable in OPA and Rego, Checkov, admission control | “You will own the preventive controls in CI, not the backlog of findings after deploy” |
Most postings I read describe the third one and hire for the first one. The candidate finds out in month two. Then they leave.
None of this makes the posting longer. It makes it shorter, because once the boundary is stated out loud you can delete the four vague bullets that were standing in for it.
Line Three, the Pager
Does this person get woken up? Amazon GuardDuty fires at 2 a.m. on an anomalous IAM API call from an unfamiliar region. Microsoft Defender for Cloud flags a suspicious key vault access. Falco catches a shell spawning inside a running container.
Somebody answers that. Say whether it is this seat. Candidates with young kids and candidates coming off a rough on-call year both want to know, and both of them will read silence as bad news.
Cloud Security Engineer Job Description Template
Copy it, cut what does not apply, and keep the parts where it names things. Vagueness is what stretched the last req to eleven weeks.
Job Title
Cloud Security Engineer. Or Senior Cloud Security Engineer if the band supports it, and put the primary provider in the body rather than the title. “AWS Cloud Security Engineer” reads to a strong Azure-side candidate as a door closing, and you may want that door open.
Three titles that cost you applicants because nobody searches for them. Cloud Security Specialist II. Information Security Engineer III (Cloud). Infrastructure Assurance Analyst. Real titles from real reqs, and all three sat.
About the Role
We run our production environment in AWS across roughly 40 accounts under AWS Organizations, with a smaller Azure footprint that came in through an acquisition. Everything is deployed through Terraform and reviewed in GitHub. You will be the second security engineer on a team of nine platform and infrastructure engineers, reporting to the Director of Security.
Your job is to make the insecure configuration hard to deploy in the first place, and to close the ones already out there. You will have write access to our infrastructure repositories. Fixes you can safely make yourself, you make yourself. We are not asking you to file a ticket and wait.
We are SOC 2 Type II today and starting a HITRUST assessment in Q2, so some of this work is evidence you will be asked to produce for an auditor. About 20 percent of the role. We would rather tell you that now.
Three things that paragraph did. It named the scale, it answered the merge-rights question before anyone had to ask, and it disclosed the compliance load instead of letting a candidate discover it in month three and start looking again.
What You Will Own in the First 90 Days
- Take ownership of our CSPM platform, tune out the noise, and get us to a findings backlog we can actually work
- Review IAM across the AWS Organization and produce a prioritized least-privilege plan, starting with roles that can assume into production
- Add security checks to the Terraform pipeline so the top five misconfiguration classes fail in CI rather than in a dashboard two weeks later
- Build the runbook for cloud credential compromise, then run a tabletop against it with the platform team
- Tell us the one thing about our cloud posture that worries you most, and what it would take to fix
That last bullet is not filler. It is the highest-signal line you can put in a cloud security posting, and it changes who applies. People who want a ticket queue skip it. People who have opinions write about it in the cover letter, and you have learned something before the first screen.
What You Bring
- Four or more years in security engineering with at least two of them primarily in AWS, Azure, or GCP
- Hands-on with cloud IAM at depth. Policy evaluation logic, role assumption, permission boundaries, service accounts, whichever of those your provider calls them
- Infrastructure as code. You have written Terraform or CloudFormation, not just read it, and you have had a module rejected in review and fixed it
- Familiarity with at least one CSPM or CNAPP platform. Wiz, Prisma Cloud, Orca, Microsoft Defender for Cloud, AWS Security Hub, whatever you had
- Container and Kubernetes security fundamentals. Image scanning, admission control, secrets handling, network policy
- Enough incident experience to be calm in the third hour of a bad one
Nice to Have, and We Mean It
- Policy-as-code with OPA and Rego, Kyverno, or Checkov
- Detection engineering in a cloud-native SIEM
- Prior SOC 2, HITRUST, FedRAMP, or PCI DSS evidence work
- AWS Certified Security Specialty, Azure AZ-500, Google Professional Cloud Security Engineer, CCSK, or CCSP
If a line is genuinely required, move it up. What kills pipelines is a preferred list eleven items long that every reader treats as the real bar. Six or fewer, and mean all of them.
Compensation and Location
$150,000 to $185,000 base plus equity and bonus, depending on depth. Hybrid, two days a week in our Denver office, with flexibility during on-call weeks. On-call is one week in five, shared with the platform team.
Post the number. A real one. In several states you have no choice, and in the rest the candidates you most want are already comparing three postings that did.
Adjusting the Template for Your Actual Cloud Footprint
The template above assumes AWS-primary with a Terraform pipeline, which is the most common shape we staff. Yours may not be.
Single cloud, deep. Name the provider in the body, name the services, and drop the multi-cloud language entirely. A posting that says “AWS, Azure, or GCP” to a company that has only ever run in one of them reads as copied from a template, because it usually was. Say EKS and IAM Identity Center and Control Tower if that is what you run. Specific gets read.
Azure-primary. The pool is smaller and it behaves differently, and the technical screen has to change with it. Azure security work lives in the management group and subscription hierarchy, in Entra ID conditional access, in Azure Policy and RBAC scope inheritance. An AWS-native candidate can learn all of it and many do, in about a quarter. Do the math first. Decide whether you will pay for that quarter, then write the posting to match, because a req that demands deep Azure and offers an AWS band gets you nothing.
GCP-primary. The smallest pool of the three, and the vocabulary differs enough to matter. Organization policy constraints, IAM conditions, VPC Service Controls, Security Command Center. A posting that describes GCP work in AWS words tells a strong GCP candidate that you have not been running this environment long. Use the real names.
Multi-cloud that arrived through an acquisition. Be honest about the ratio. “Primarily AWS with a growing Azure footprint you will help bring under the same controls” is accurate, appealing, and true of about a third of the reqs I see. “Expert-level AWS and Azure required” describes maybe four percent of the market and adds real money to the band.
Kubernetes-heavy. Say so, prominently, in the first third of the posting. Kubernetes production use reached 82 percent of container users in the 2025 CNCF Annual Cloud Native Survey released in January 2026, so plenty of candidates have been near a cluster. Near is not the same as owning admission control. If this role writes Gatekeeper or Kyverno policy that will block a deploy at 4 p.m. on a Friday, that is a specific person, and you should describe the actual work instead of listing Kubernetes as a keyword.
Worth separating out, since it comes up on nearly every intake call. If what you need is somebody to build and run the cloud rather than secure it, that is a different req and a different template, and we keep a cloud engineer job description template for exactly that case. The overlap in tooling is real. The overlap in reflexes is not.
Five Lines That Quietly Cost You Cloud Security Finalists
1. “Monitor cloud environments for security threats.”
Monitor with what? Owning a CSPM platform is a different job from watching a SIEM, and both are different from building detections. That sentence appears in roughly half the cloud security postings I read, and it tells a strong candidate nothing except that the person who wrote the req may not know either.
2. Ten-plus years of cloud experience.
Do the arithmetic on that one. Azure Resource Manager shipped in 2015. Kubernetes hit 1.0 the same year. Terraform is from 2014. Somebody with ten years of genuine cloud security depth was doing this before most enterprises had a second account. Not many exist. They are expensive. Five to seven years is a real, large, hireable pool. Ten is a mostly imaginary one.
3. A certification wall in the requirements block.
Cloud certifications carry more signal than most, because the AWS Security Specialty and AZ-500 exams sit close to the daily work. Put them under preferred anyway. Some of the strongest cloud security engineers I have placed came out of platform engineering and never sat an exam, and if your applicant tracking system screens on the acronym you will never see them.
4. Silence on remediation authority.
Covered above, and it is the expensive one. Say it in the posting. One sentence, up in the About the Role paragraph where a candidate will actually read it, rather than buried in bullet nine of the responsibilities list. Every week that line is missing is a week you spend running interviews to answer a question you could have answered for free.
5. Compliance framed as the whole job when it is 20 percent, or hidden when it is 60 percent.
Both directions burn you. A posting that leads with SOC 2 reads like a GRC role, the engineers stop reading somewhere around the third control reference, and you finish the month with a pipeline full of auditors applying to an engineering seat. A posting that never mentions FedRAMP, when the person will in fact spend three days a week writing control narratives for an authorization, produces an accepted offer and a resignation in month five. I have watched that exact sequence twice. Put the percentage in the posting. Nobody has ever declined an offer because the honesty was inconvenient.
What Belongs on the Comp Line
The short version, because we cover the full picture in our cloud security engineer salary guide and there is no sense duplicating it here.
Cloud security sits above general information security, and published averages will not show you that clearly, because most of them blend the two. O*NET OnLine, sponsored by the U.S. Department of Labor, puts the 2025 median annual wage for information security analysts at $129,180, with roughly 16,000 projected annual openings across the 2024 to 2034 window. That is the floor of the conversation rather than the middle of it. Built In reports an average base of $140,052 for cloud security engineers specifically, total compensation averaging $166,163, and a reported range running from $95,000 to $250,000.
Our own band on the searches we fill runs $105,000 to $215,000 base from associate through senior, with staff and principal seats going past $215,000 at large technology employers. Post a range. A narrow honest one beats a wide meaningless one, and “commensurate with experience” reads in 2026 as a company that has not decided.
One more reason not to lowball the posting. The ISC2 2025 Cybersecurity Workforce Study found cloud security to be the single top technical skill hiring managers are looking for, named by 29 percent of them, while only 34 percent of security professionals rate their own cloud knowledge as significant. You are competing inside a thin slice of an already thin market. Your posting is doing more work than you think.
What Comes Up on the Intake Call
Our security team finds the problems and platform engineering fixes them. Does the posting really need to say that?
Yes, in one sentence, near the top. Candidates price remediation authority into their decision the way they price on-call, and a senior cloud security engineer who assumed they would be shipping fixes and then finds out they are filing tickets tends to leave inside a year. Write it plainly. “You will partner with platform engineering, who own and merge infrastructure changes.” Some people want that job. Write for them.
We are AWS with one Azure subscription from an acquisition. One req or two?
One req. Write it AWS-primary and describe the Azure work as something the hire will help bring under the same controls, which is both true and appealing to people who like a clean project. Two reqs is right only when the Azure footprint is large enough to keep somebody busy full time, and a single inherited subscription almost never is.
Is a cloud security engineer just a cloud engineer who reads the security documentation?
Different reflexes, mostly. A cloud engineer optimizes for the thing working. A cloud security engineer asks what happens when it works for the wrong person. On a resume the toolsets look interchangeable. They are not. The move from platform engineering into cloud security is one of the better transitions I see, so if you have an internal cloud engineer with a security streak, have that conversation before you post anything at all.
How much Kubernetes should we actually require?
It depends on whether this seat writes admission policy or consumes somebody else’s. Where a platform team fully manages your clusters and the security engineer reviews their work, ask for fundamentals and mean it. Image scanning, secrets handling, why a privileged container matters. Where the role owns Gatekeeper, Kyverno, or Falco tuning, that is a narrower and more expensive candidate, and the posting has to say the words so the right people select themselves in.
Which cloud security certifications are worth naming?
The AWS Certified Security Specialty and Azure AZ-500 track the daily work closely enough to be genuine signal, and Google’s Professional Cloud Security Engineer does the same on that platform. CCSK and CCSP are vendor-neutral and read as more architectural. Name two or three under preferred, never in requirements, and do not let a resume screen filter on them.
How long does one of these reqs usually take?
Our average time-to-hire across IT roles is 17 days, and cloud security lands above that, closer to three to five weeks from a clean intake to an accepted offer. The variable is almost never sourcing. It is how long the internal team takes to agree on the boundary questions above, which is why we ask them on the first call instead of the third.
Should the posting mention SOC 2 or FedRAMP if that is the actual driver?
Mention it, with the percentage attached. “Roughly 20 percent of this role supports our SOC 2 and HITRUST evidence” filters correctly in both directions. Engineers who hate audit work opt out early, which is a gift, and the ones who are comfortable with it will say so in the first screen. Hiding it is the only choice with a bad outcome.
If You Change One Thing Before You Post
Add the sentence about who merges the fix. Not the whole template, not a rewrite. One sentence. It is the cheapest edit in this post and it resolves the confusion that stretched that Austin req to eleven weeks.
Then go look at your interview loop, because a posting that draws the boundary and a loop that ignores it puts you back where you started. We wrote up what the good loops test in our cloud security engineer interview questions piece, and the fuller version of the hiring process, sourcing and offer strategy included, sits in our guide on how to hire a cloud security engineer.
KORE1 has staffed technology desks since 2005, across more than 30 U.S. metros, with a 92 percent twelve-month retention rate on the people we place. Our cloud security recruiters run these searches on both contract and direct-hire terms inside the wider cybersecurity staffing practice. If you want a second set of eyes on a posting before it goes live, or the search has already been open too long, talk to a recruiter on our team. Bring the boundary answers. We will find the rest.
