Sr. Manager, Security — Continuous Monitoring v 2.0
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). Do NOT repeat the job title as a heading. We need to map content to these headings.
We have sections: About the role (description of role). Responsibilities (list of duties). Requirements (maybe "What We Look For"). Qualifications (maybe similar). Skills (maybe technical depth). Benefits (explicit Benefits section). Pay (Pay Range Transparency). Schedule (not present). So we should not include Schedule if no content.
We need to preserve all substantive information, not invent. Remove boilerplate: cookie/navigation/legal/EEO etc. The posting includes some repeated "About Databricks" twice; we should include only once? Probably include company description under maybe "About Databricks" but not a required heading; we could incorporate into About the role? The instruction: use headings for those specific categories. We can include extra sections not listed? It says use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings, but likely we should stick to those. However we need to preserve all substantive information; we can put company description under About the role or maybe a separate "About Databricks" but not required. Safer to include it under About the role as part of role description.
We need to use - for any list of duties/requirements/benefits. So for responsibilities list, we need to extract bullet points. The posting has many paragraphs; we can convert each sentence into list items? Might be too granular. Better to identify explicit bullet-like lists: The "Impact You Will Have" section has subheadings: Team Building & People Leadership, Control Measurement Program Ownership, Posture Visibility & Executive Intelligence, Cross-Functional Partnership & Execution, Technology Decisions. Under each there are bullet-like sentences starting with verbs. We could treat each as list items under Responsibilities.
Similarly "What We Look For" is a list of requirements.
Benefits section: just a paragraph describing benefits; we can put as
.
Pay: we have pay ranges per zone; we can present as
- Zone 1: $228,600—$314,250 USD
etc.
Schedule: none -> omit.
We must not include filler like "commensurate with experience". Not present.
We must not include Job ID/requisition numbers; we can drop the leading "RDQ227R1175". Also drop location encouragement line? Might be considered metadata; we can fold into short maybe but not required. The instruction: do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. So we can drop that line.
Also remove duplicated lines, cookie/navigation/legal/EEO etc. At end there is truncated "Our Commitment to Diversity and Inclusion ..." incomplete; we should drop that as boilerplate.
Now craft HTML.
Structure:
About the role
... company description and role overview ...
Responsibilities
- ...
...
Requirements
- ...
...
Maybe also Qualifications and Skills? Could split Requirements into Qualifications and Skills but we have only one list. Could put Requirements as qualifications, and Skills as separate list of technical skills (e.g., Python, cloud platforms, CSPM, etc.). The "What We Look For" includes technical depth, cloud security knowledge, compliance frameworks, etc. Could separate into Qualifications (experience, education) and Skills (technical). Let's parse:
What We Look For bullet points:
- 2+ years of prior management experience leading Engineering or Security engineering teams.
- Typically 12+ years of experience, or an advanced degree plus 8 years, preferably focused on security engineering, security posture monitoring, or compliance automation.
- Sufficient technical depth to review the work of the team: can read and critique Python automation, evaluate an integration architecture, and assess whether a monitoring approach will hold up in production.
- Solid understanding of security controls and where they fail in practice — identity and access, configuration management, logging coverage, vulnerability management, and data protection — enough to judge whether a given measurement is telling you anything useful.
- Solid cloud security knowledge across at least one major platform (AWS, Azure, GCP) — IAM, audit logging, CSPM concepts, and cloud-native security services.
- Working knowledge of compliance frameworks (SOC 2, ISO 27001, FedRAMP, or equivalent) at a level sufficient to assess whether a control monitoring design will satisfy an auditor.
- Previous experience building security posture monitoring or compliance automation at scale, with attention to accuracy, coverage, and cost tradeoffs (experience with Databricks is preferred).
- Focused on defining and driving efficiencies and improvements within the team; accountable for defining and achieving targets (e.g. OKRs, KPIs).
- Makes effective priority decisions on resourcing and alignment within the team.
- Strong communicator across technical, GRC, and executive audiences — can explain automation architecture to auditors and compliance requirements to engineers.
Nice to Have list separate; we could treat as Skills? But we can include them under Skills maybe.
We could make Qualifications: experience, education, years. Skills: technical depth, cloud security, compliance frameworks, Python, etc. Benefits: as given.
Pay: as given.
Let's craft.
We need to ensure we don't include filler like "commensurate with experience". Not present.
Now produce HTML fragment.
We'll include:
About the role
Databricks is the data and AI company. More than 12,000 organizations worldwide — including Comcast, Condé Nast, Grammarly, and over 50% of the Fortune 500 — rely on the Databricks Data Intelligence Platform to unify and democratize data, analytics and AI. Databricks is headquartered in San Francisco, with offices around the globe and was founded by the original creators of Lakehouse, Apache Spark™, Delta Lake and MLflow. The Continuous Monitoring (ConMon) team builds and operates the engineering infrastructure that keeps Databricks' security control posture visible, measurable, and defensible at all times. The team builds automation that continuously assesses whether security controls are actually working across cloud environments, SaaS platforms, identity systems, and enterprise applications — surfacing drift, coverage gaps, and control failures as they happen rather than at the next audit. The role: Databricks is looking for a Senior Manager to lead the Continuous Monitoring team. You will own the engineering function that measures whether Databricks' security controls are working — across cloud infrastructure, identity, SaaS, and enterprise systems — and turns that measurement into something the Security organization, and its auditors, can rely on. This includes demonstrating control posture against the frameworks the business carries (SOC 2, ISO 27001, FedRAMP, PCI DSS, and emerging AI governance requirements), but the underlying question is broader: are the controls Databricks depends on actually in place and operating everywhere they are supposed to be? This is an engineering management role. The team writes production Python, operates data pipelines against cloud and SaaS APIs, and integrates with GRC and security tooling. Success is measured in control coverage, the accuracy and timeliness of what the team reports, and how quickly gaps get to the people who can close them. The role requires enough technical depth to review that work credibly, and enough judgement to prioritize the controls where measurement actually reduces risk. As the leader of Continuous Monitoring, you'll be responsible for growing and developing the team; setting a clear vision, priority, and strategy; making the case for the headcount and tooling the program needs; and building durable partnerships across GRC (SAC, SAF, Governance, Risk Management, TPRM), IT, Legal, and Engineering — the organizations that own the controls your team monitors.
Then Responsibilities: we can list from Impact You Will Have sections.
Let's extract each bullet:
Team Building & People Leadership:
- Hire strong Security Software Engineers who bring genuine engineering skill to compliance automation.
- Support engineers in their career development with clear, specific feedback; develop senior ICs into technical leaders and grow the next generation of security engineering managers.
- Set and hold a high bar for engineering quality: code review standards, reliability and observability expectations for automation pipelines, and documentation that remains useful across audit cycles and team changes.
- Build a team that combines GRC domain knowledge with software engineering discipline, and hire for both.
Control Measurement Program Ownership:
- Own the strategy and roadmap for Databricks' continuous monitoring platform — control state collection at cloud scale, continuous posture assessment, security and GRC tooling integration, and remediation tracking.
- Define what the program measures and why: prioritize the controls whose failure would matter most to Databricks' security posture, rather than defaulting to the set a given framework happens to enumerate.
- Ensure coverage keeps pace with the business — new cloud environments, new products and services, new certifications and regulatory obligations, and AI governance controls that current tooling does not yet assess.
- Reduce manual evidence collection systematically; set and track targets for automated control coverage, freshness, and audit burden on Engineering teams.
- Own the accuracy of the team's output, including false positive rates; findings should be reliable enough that control owners act on them without re-verification.
Posture Visibility & Executive Intelligence:
- Own the security posture dashboards, metrics, and reporting that give Security and GRC leadership an accurate, timely view of control health across the company.
- Define the metrics the program reports on — control coverage, drift, time-to-remediate, and where the organization is exposed — and build the reporting that leadership uses to make security investment and prioritization decisions.
- Present the team's findings to senior leadership: control gaps and drift, their risk implications, and the effort required to remediate them.
- Make the same measurement data serve both audiences: evidence an auditor will accept, and signal the company can act on.
Cross-Functional Partnership & Execution:
- Establish productive working relationships with GRC (SAC, SAF, Governance, Risk Management, TPRM), Enterprise Security, Product Security, Security Operations, IT, Legal, and Engineering leadership — the teams who own the controls, the evidence, and the remediation.
- Partner with Enterprise Security and Product Security so control measurement reflects how systems are actually built and configured, and feed coverage gaps back to the teams who own those controls.
- Partner with SAC and SAF to ensure monitoring output meets auditor and 3PAO evidence standards, and with Governance to keep control monitoring aligned to policy as standards evolve.
- Coordinate with Risk Management and Security Operations on metric definitions and reporting boundaries so the organization gets one coherent picture of control health rather than three overlapping ones.
- Coordinate execution across teams to unblock cross-cutting initiatives: telemetry gaps in Engineering-owned systems, GRC platform migrations, and multi-quarter automation programs.
- Make effective priority and resourcing decisions within the team; be accountable for defining and achieving the team's OKRs and KPIs.
Technology Decisions:
- Lead build-vs.-buy evaluations for CSPM, SSPM, GRC automation, and security posture tooling; assess platforms on integration capability, measurement fidelity, maintenance cost, and fit with existing pipelines, and make the recommendation to Security and GRC leadership.
- Keep the program's operating costs defensible — cloud spend, tooling, and the engineering time monitoring consumes — and be able to explain the tradeoff between monitoring coverage and what it costs to run at scale.
- Track what the program will need to measure next — changes in Dat
- for any list of duties/requirements/benefits. So for responsibilities list, we need to extract bullet points. The posting has many paragraphs; we can convert each sentence into list items? Might be too granular. Better to identify explicit bullet-like lists: The "Impact You Will Have" section has subheadings: Team Building & People Leadership, Control Measurement Program Ownership, Posture Visibility & Executive Intelligence, Cross-Functional Partnership & Execution, Technology Decisions. Under each there are bullet-like sentences starting with verbs. We could treat each as list items under Responsibilities.
Similarly "What We Look For" is a list of requirements.
Benefits section: just a paragraph describing benefits; we can put as
. Pay: we have pay ranges per zone; we can present as
- Zone 1: $228,600—$314,250 USD etc. Schedule: none -> omit. We must not include filler like "commensurate with experience". Not present. We must not include Job ID/requisition numbers; we can drop the leading "RDQ227R1175". Also drop location encouragement line? Might be considered metadata; we can fold into short
- ... ...
- ... ...
maybe but not required. The instruction: do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. So we can drop that line. Also remove duplicated lines, cookie/navigation/legal/EEO etc. At end there is truncated "Our Commitment to Diversity and Inclusion ..." incomplete; we should drop that as boilerplate. Now craft HTML. Structure:
About the role
... company description and role overview ...
Responsibilities
Requirements
About the role
Databricks is the data and AI company. More than 12,000 organizations worldwide — including Comcast, Condé Nast, Grammarly, and over 50% of the Fortune 500 — rely on the Databricks Data Intelligence Platform to unify and democratize data, analytics and AI. Databricks is headquartered in San Francisco, with offices around the globe and was founded by the original creators of Lakehouse, Apache Spark™, Delta Lake and MLflow. The Continuous Monitoring (ConMon) team builds and operates the engineering infrastructure that keeps Databricks' security control posture visible, measurable, and defensible at all times. The team builds automation that continuously assesses whether security controls are actually working across cloud environments, SaaS platforms, identity systems, and enterprise applications — surfacing drift, coverage gaps, and control failures as they happen rather than at the next audit. The role: Databricks is looking for a Senior Manager to lead the Continuous Monitoring team. You will own the engineering function that measures whether Databricks' security controls are working — across cloud infrastructure, identity, SaaS, and enterprise systems — and turns that measurement into something the Security organization, and its auditors, can rely on. This includes demonstrating control posture against the frameworks the business carries (SOC 2, ISO 27001, FedRAMP, PCI DSS, and emerging AI governance requirements), but the underlying question is broader: are the controls Databricks depends on actually in place and operating everywhere they are supposed to be? This is an engineering management role. The team writes production Python, operates data pipelines against cloud and SaaS APIs, and integrates with GRC and security tooling. Success is measured in control coverage, the accuracy and timeliness of what the team reports, and how quickly gaps get to the people who can close them. The role requires enough technical depth to review that work credibly, and enough judgement to prioritize the controls where measurement actually reduces risk. As the leader of Continuous Monitoring, you'll be responsible for growing and developing the team; setting a clear vision, priority, and strategy; making the case for the headcount and tooling the program needs; and building durable partnerships across GRC (SAC, SAF, Governance, Risk Management, TPRM), IT, Legal, and Engineering — the organizations that own the controls your team monitors.
Then Responsibilities: we can list from Impact You Will Have sections. Let's extract each bullet: Team Building & People Leadership: - Hire strong Security Software Engineers who bring genuine engineering skill to compliance automation. - Support engineers in their career development with clear, specific feedback; develop senior ICs into technical leaders and grow the next generation of security engineering managers. - Set and hold a high bar for engineering quality: code review standards, reliability and observability expectations for automation pipelines, and documentation that remains useful across audit cycles and team changes. - Build a team that combines GRC domain knowledge with software engineering discipline, and hire for both. Control Measurement Program Ownership: - Own the strategy and roadmap for Databricks' continuous monitoring platform — control state collection at cloud scale, continuous posture assessment, security and GRC tooling integration, and remediation tracking. - Define what the program measures and why: prioritize the controls whose failure would matter most to Databricks' security posture, rather than defaulting to the set a given framework happens to enumerate. - Ensure coverage keeps pace with the business — new cloud environments, new products and services, new certifications and regulatory obligations, and AI governance controls that current tooling does not yet assess. - Reduce manual evidence collection systematically; set and track targets for automated control coverage, freshness, and audit burden on Engineering teams. - Own the accuracy of the team's output, including false positive rates; findings should be reliable enough that control owners act on them without re-verification. Posture Visibility & Executive Intelligence: - Own the security posture dashboards, metrics, and reporting that give Security and GRC leadership an accurate, timely view of control health across the company. - Define the metrics the program reports on — control coverage, drift, time-to-remediate, and where the organization is exposed — and build the reporting that leadership uses to make security investment and prioritization decisions. - Present the team's findings to senior leadership: control gaps and drift, their risk implications, and the effort required to remediate them. - Make the same measurement data serve both audiences: evidence an auditor will accept, and signal the company can act on. Cross-Functional Partnership & Execution: - Establish productive working relationships with GRC (SAC, SAF, Governance, Risk Management, TPRM), Enterprise Security, Product Security, Security Operations, IT, Legal, and Engineering leadership — the teams who own the controls, the evidence, and the remediation. - Partner with Enterprise Security and Product Security so control measurement reflects how systems are actually built and configured, and feed coverage gaps back to the teams who own those controls. - Partner with SAC and SAF to ensure monitoring output meets auditor and 3PAO evidence standards, and with Governance to keep control monitoring aligned to policy as standards evolve. - Coordinate with Risk Management and Security Operations on metric definitions and reporting boundaries so the organization gets one coherent picture of control health rather than three overlapping ones. - Coordinate execution across teams to unblock cross-cutting initiatives: telemetry gaps in Engineering-owned systems, GRC platform migrations, and multi-quarter automation programs. - Make effective priority and resourcing decisions within the team; be accountable for defining and achieving the team's OKRs and KPIs. Technology Decisions: - Lead build-vs.-buy evaluations for CSPM, SSPM, GRC automation, and security posture tooling; assess platforms on integration capability, measurement fidelity, maintenance cost, and fit with existing pipelines, and make the recommendation to Security and GRC leadership. - Keep the program's operating costs defensible — cloud spend, tooling, and the engineering time monitoring consumes — and be able to explain the tradeoff between monitoring coverage and what it costs to run at scale. - Track what the program will need to measure next — changes in Dat