Anthropic
Publicado originalmente en greenhouse · Aplica desde el sitio de la empresa para mejor experiencia.
<div class="content-intro"><h2><strong>About Anthropic</strong></h2> <p>Anthropic’s mission is to create reliable, interpretable, and steerable AI systems. We want AI to be safe and beneficial for our users and for society as a whole. Our team is a quickly growing group of committed researchers, engineers, policy experts, and business leaders working together to build beneficial AI systems.</p></div><h2><strong>About the role</strong></h2> <p>Anthropic operates and is building data center campuses around the world, run day to day through operating partners, site vendors, and contracted security services. Things go wrong at those sites the way they go wrong at any critical infrastructure: access issues, contractor incidents, protests, weather, equipment failures, and occasionally something with the potential for global impact. Today, what counts as an incident, who gets told, and how it is reported vary by site and by vendor.</p> <p>As Lead for Crisis and Incident Management, you will build the program that removes that variance, and you will build it with the people who have to live with it. The first job is definition: working with operating partners, site security vendors, managed-service providers, and internal teams to agree on what counts as a minor escalation versus a major incident of global impact, the severity levels in between, the thresholds that move an event from one level to the next, and who gets told, how fast, and in what format. The second job is adoption: turning those definitions into playbooks, training, and exercises so that responders at every site and vendor actually respond the right way, and running the after-action reviews that show where they did not. The third job is measurement: defining the incident metrics, building the reporting, and giving leadership a regular, accurate picture of how response is performing across the fleet. Underneath all three sits the cross-functional work of getting partners to buy in, because a framework no partner has signed up to is a document, not a program.</p> <p>Continuous coverage is part of the picture. As the program matures, you will shape a 24/7 monitoring and response capability through GSOC-type managed services and site vendors, so that the framework holds at three in the morning at any site in the fleet. That build-out follows from the definitions and partner agreements above rather than replacing them. When a major incident does happen, you run it: activation, coordination, leadership communication, stand-down, and the after-action review that makes the program better.</p> <p>This is a program-building role, not a shift-supervision role. The deliverable is a framework that partners have adopted, that works at any site, and that reports on itself, run largely through vendors and managed services rather than a large in-house team. Where existing processes and vendor arrangements don't support that, you will have the authority, and the expectation, to change them.</p> <p>Role boundaries. This seat is distinct from the Data Center Security Delivery Lead (who owns security through construction, commissioning, and handover on new builds), from regional security operations leads (who own steady-state regional programs and vendor relationships site by site), and from the team's systems-engineering roles (who build platforms and tooling). This role owns the horizontal incident and crisis layer across the operating fleet: the incident definitions and severity framework, partner adoption and governance, incident reporting and metrics, major incident command, post-incident review, and, as it develops, the 24/7 coverage model, applied consistently across every site and vendor.</p> <h2><strong>Key responsibilities</strong></h2> <p>You will build and own the global crisis and incident management program for data center physical security.</p> <ul> <li> <p>Incident definition and severity framework: define, with partners, what counts as an incident and the tiers from minor site escalation to major incident of global impact, with clear thresholds, escalation and activation criteria, notification requirements, and decision rights at each tier. This is the foundation the rest of the program is built on.</p> </li> <li> <p>Cross-functional partner buy-in and governance: bring operating partners, site security vendors, managed-service providers, and internal teams into the definition work so the framework is theirs as well as ours, and establish the governance (owners, review cadence, change process) that keeps it current as the fleet grows.</p> </li> <li> <p>Adoption and response readiness: turn the framework into playbooks, training, and tabletop and functional exercises across sites and vendors, so responders know the right response before the next real incident and the escalation chain is tested by design.</p> </li> <li> <p>Metrics and reporting: define the incident metrics that show whether definitions are being applied and whether response is improving, build the dashboards and reporting behind them, and own the executive reporting cadence, from real-time notification through leadership escalation and executive summaries.</p> </li> <li> <p>Vendor and managed-service consistency: hold multiple vendors and GSOC-type providers to one standard: common definitions, common procedures, common reporting formats, common escalation triggers, with performance measured and enforced.</p> </li> <li> <p>Major incident management: run the crisis process when an incident has multi-site or global impact: activation, coordination across sites, vendors, and internal teams, decision support to leadership, and formal stand-down.</p> </li> <li> <p>Post-incident review and improvement: run structured after-action reviews, track corrective actions to closure, and feed lessons back into definitions, playbooks, procedures, and vendor contracts.</p> </li> <li> <p>24/7 coverage model: as the program matures, design and run an always-on monitoring, escalation, and response capability through GSOC-type managed services and site security vendors, achieving continuous coverage without building a large in-house shift operation.</p> </li> </ul> <h2><strong>Minimum qualifications</strong></h2> <ul> <li> <p>Have built or substantially rebuilt an incident management or crisis management program (not just operated within one), including the definitions and severity model at its core, and can describe what existed before you, what you changed, and how you know it worked.</p> </li> <li> <p>Have brought partners you don't control (operators, vendors, internal teams) into agreeing on definitions and procedures, and can describe how you won that buy-in and kept it.</p> </li> <li> <p>Have driven adoption: you have taken a framework from paper into playbooks, training, and exercises, and can point to responders behaving differently as a result.</p> </li> <li> <p>Have defined incident metrics and built the reporting behind them, and can explain which measures actually told leadership something and which did not.</p> </li> <li> <p>Know data centers: you have worked physical security in or around data center or comparable critical-infrastructure operations, and understand the environment of operating partners, contractors, and 24/7 site activity.</p> </li> <li> <p>Have run major incidents end to end: activation, multi-party coordination, leadership communication, stand-down, and after-action, and can walk through specific ones.</p> </li> <li> <p>Have held vendors or managed services (a GSOC, monitoring provider, or guard force) to defined performance standards, with evidence rather than assurances.</p> </li> <li> <p>Can make the severity call quickly on incomplete information, defend it either way, and adjust as facts arrive.</p> </li> <li> <p>Write clearly under pressure: your incident report-outs can go to executives without editing.</p> </li> <li> <p>Work through influence across sites, vendors, and internal teams you don't control; you sh