MTF Institute Research Team · 6 October 2026
Independent methodological review of source recodes: MTF Institute Research QA, completed 6 October 2026
Research archive: The exact Zenodo version contains the three-page PDF report, the 109-row vacancy source index, the aggregate Role Requirements Matrix, and the methodology and data dictionary.
Executive summary
Cloud security operations work in this U.S. vacancy sample joins configuration, identity, monitoring, remediation and automation. In 109 distinct employer requisitions with a current role-matched application path, the most frequent explicitly coded duties were cloud controls or posture (72/109), monitoring or detection (71/109), identity or access (62/109), and automation or infrastructure as code (60/109). Controls/posture and monitoring/detection appeared together in 46/109 postings. These are mentions within a structured purposive sample, not estimates of national hiring prevalence or proof that a particular tool or operating model is universal.
The practical work is more specific than a job title. The postings describe building or tuning controls, investigating signals and findings, producing documentation and detections, and coordinating with infrastructure, application or service owners. Their authority and work rhythm vary by employer. “Cloud security operations” appears as a description of work in source text, but none of the 109 accepted titles uses that exact phrase.
The question and the sample
This study asks: What operational duties, outputs, methods, behavioral actions, tools, decisions, interfaces and work rhythms do current U.S. employer requisitions explicitly ask for in cloud security and Zero Trust-related roles? The unit is one distinct requisition, not one employer or one occupied job. The declared geography is the United States. Inclusion required an explicit U.S. workplace or U.S.-eligible remote scope, a role-matched application path observed on 6 October 2026, and substantive hands-on cloud security responsibility. Engineer, analyst and adjacent titles were considered on their actual duties, including cloud identity, posture, workload or network protection, cloud monitoring, incident support and automation.
Initial collection yielded 118 distinct requisitions. Source and geography checks selected 109 for this study: 35 from the main employer/ATS lane, 31 from Greenhouse and identity-focused collection, 16 from posture/detection collection, and 27 from other boards and iCIMS. Nine records were excluded: two sign-in-gated application routes without visible applicant fields (V022, V028); three award-contingent positions (O062, O068, O070); one architecture-led role (O072); one management role (I087); one general infrastructure software engineering role (I100); and one remote role whose page did not establish a U.S. workplace (G047). The 118 are an inclusive collection count, not the denominator for the findings below. Search-log entries were not treated as unique vacancies.
Researchers deduplicated by employer and requisition ID, then checked title, location, URL and materially identical content. Every accepted row retained a direct employer or authorized ATS URL and retrieval date. All 109 accepted requisitions had a live, role-matched application route on 6 October 2026. Verification ranged from visible applicant fields to an employer Apply control or a role-specific Workday start; the source URL and application evidence tier are recorded for each requisition in the accompanying source index. The postings were then source-recoded for assigned duties, work products, methods, observable behaviors, tools, criteria, cadence, interfaces and authority. Each topic is counted once at most per requisition, while one requisition may mention several topics. Unknown or uncoded text is not counted as absence of an employer requirement.
Duties and outputs: what the roles ask people to do
| Explicitly coded duty topic | Requisitions |
|---|---|
| Cloud controls and posture | 72/109 |
| Monitoring and detection | 71/109 |
| Identity and access | 62/109 |
| Automation and infrastructure as code | 60/109 |
| Vulnerability work and remediation | 55/109 |
| Incident response | 44/109 |
| Architecture or threat modeling | 42/109 |
| DevSecOps or container work | 42/109 |
| Compliance or governance-related work | 37/109 |
| Zero Trust or network controls | 31/109 |
These are overlapping topics, not mutually exclusive job types. The most recorded work-product categories were controls or guardrails (62/109), findings and remediation work (47/109), security tooling or automation (42/109), documentation or runbooks (36/109), and detections or telemetry (35/109). Reports, metrics or audit evidence appeared in 29/109; architecture or design products in 27/109. A category was counted only when the source recode identified an actual output; its presence does not establish a common format across employers.
Individual postings show how the categories combine. SmarterDx's Senior Security Engineer writes and tunes SIEM detections, onboards logs, investigates alerts, works AWS posture findings and writes runbooks. The posting names a Staff Security Engineer who sets strategy, while the advertised role operates and improves detection coverage. Appspace's Cloud Security Engineer combines alert review with cloud configuration, access and firewall reviews, customer diagrams and incident-plan documentation. These are two employer examples; neither defines every role in the sample.
Methods, tools and working behaviors
The leading hard-method topics were cloud-platform security (86/109), automation, infrastructure as code or programming (79/109), monitoring, detection or incident response (74/109), identity and access methods (73/109), vulnerability or posture methods (65/109), and network, container or data security (62/109). Framework-related methods appeared in 52/109 and architecture or threat-modeling methods in 29/109. The categories combine source-recoded methods and overlap within a requisition.
Named terms in the job text include AWS (71/109), Terraform (52/109), Azure (48/109), Python (47/109), Kubernetes (41/109) and GCP (38/109). These are exact recorded terms rather than consolidated vendor-family shares: related aliases, products and service names can be separate tags. A mention may describe desired candidate experience rather than a deployed tool, so the list should be read as hiring language, not installed-base measurement.
The recode also preserved workplace actions. Collaboration with named partners or teams appeared in 74/109, communication or documentation actions in 65/109, mentoring or guidance in 32/109, prioritization or judgment in 29/109, explicit ownership in 21/109, and problem solving or adaptation in 13/109. For example, LaunchDarkly's Product Security Engineer investigates and prioritizes CNAPP findings, routes them to service owners and closes the loop; it also leads risk-based threat modeling. This accepted posting sits at the cloud-posture/product-security boundary and illustrates why a topic count should not be mistaken for a uniform job description.
Levels, interfaces and decision boundaries
Titles in the accepted cohort span general security engineering (36/109), cloud security engineering (33/109), infrastructure or platform security (12/109), identity or Zero Trust (7/109), detection/SOC (6/109), DevSecOps (5/109), architecture/consulting (3/109), data or product security (3/109), and other titles (4/109). These are mutually exclusive analytical labels, not a formal occupational taxonomy. Fifty-five of 109 titles carried no explicit seniority token; 34 carried a senior token, 11 staff, three principal, two lead, three a numbered level and one associate. Titles alone do not establish decision rights or experience requirements.
The 109 requisitions came from 102 recorded publishers. Booz Allen Hamilton contributed three and five publishers contributed two each; the top five contributed 11/109. The set spans different employers and role contexts but remains shaped by accessible pages, search terms and repeated language within an employer. It cannot support a sector-wide or national comparison.
Named interfaces were captured in 107/109 rows and positive decision or authority wording in 93/109. These often mean owning a control, leading a review, recommending a pattern or coordinating a fix; the exact boundary is local to the posting. Harris Associates describes hands-on Entra identity, Terraform and Azure security work alongside DevOps, data and application teams, with changes moving through a gated review flow. In its first-responder role, the engineer may resolve an issue or escalate as needed, but the page does not name the next destination. LaunchDarkly routes findings to service owners as routine remediation workflow; that is distinct from a formal escalation threshold. In another accepted posting, Nakupuna names this engineer as the technical escalation point for complex infrastructure, network or security issues; any further route is unstated.
Work rhythm and qualifications
Only 5/109 recoded postings explicitly assign a daily security task. Another five describe daily collaboration or tool use without a specific daily security-control task. Lifecycle or event-based work appears in 82/109. No weekly or monthly security-task interval was explicit at this coding depth; one posting specified a quarterly access review. Separately, 22/109 contained office, on-call or availability schedules. Harris Associates specifies an individual on-call rotation of about one week per month and patching roughly three or four Saturdays per year. These are schedule and participation facts, not evidence that all cloud security tasks recur weekly or monthly. One accepted posting contains a complete escalation trigger and destination; another contains a partial escalation mention. Blank fields do not mean that an employer has no schedule or escalation procedure.
Education or experience evidence was recorded in 102/109 rows. A source section explicitly labelled Required or equivalent appeared in 71/109, and a Preferred or equivalent section in 89/109. Specific item-level required lists could be audited in 53/109 and preferred lists in 69/109. In one collection lane, headings and experience snippets were preserved separately, so the snippets could not safely be promoted into a required or preferred item. These coverage counts are distinct from claims about the frequency of any single degree, certification or experience threshold.
Interpretation and limits
The combined picture is operationally broad: the same employer can ask for control implementation, detection, identity work and remediation. Within this sample, cloud posture and detection co-occur in 46/109 postings. That intersection is useful for understanding role overlap; it says nothing about causation, national prevalence or the proportion of work time spent on either task. Exact occupational naming also remains unsettled: 37/109 titles contain “Cloud Security,” 88/109 contain “Security Engineer,” and three contain “Zero Trust,” while none says “Cloud Security Operations” exactly.
This is a structured purposive sample of accessible U.S. employer and ATS requisitions, not a probability sample or a national sampling frame. Pages and application routes may change after the 6 October 2026 check. The collection emphasizes engineer and adjacent technical roles, with different source-page detail and some employer concentration. The recoded fields describe what postings state; they do not measure work actually performed, employer adoption or tool effectiveness. Unstated fields remain unknown. Multiple topic tags from one posting are not independent employer votes.
This vacancy study is separate from MTF Institute's review of current cloud-security changes, which uses a different evidence base. Vacancy mentions are not used here to establish that a technology is a recent trend. Employer postings remain copyrighted: this report uses original analysis, brief paraphrases and direct links, without reproducing full advertisements or proprietary materials.