# How Sublime Security replaced four tools with one platform and finally got visibility across support, security, and engineering * **15 to 90** licenses adopted organically across three teams * **3 teams** on one platform with no top-down mandate * **Hours to minutes** for incident reporting that previously required manual UTC calculations * Support calls **automatically** trigger incidents, replacing a multi-tool workaround --- When support tried to buy incident.io, security unblocked the deal. When engineering found out, they showed up asking for seats before anyone offered them. Fifteen licenses quickly became 90. ### Three teams, three sets of broken tools Sublime Security's support, security, and engineering teams each ran their own incident processes. None of them were happy with what they had. But the pain looked different from every angle. **Support needed to wake people up and talk to customers. That shouldn't require three tools.** Korey Marciniak, Head of Support, joined Sublime when the support team was a single person. By the time he started evaluating tools, the team had grown past seven. His requirements were deceptively simple: something that pages on-call support engineers for emergencies, a status page for customer communication, and integration with Slack where the team already lives. > I've used PagerDuty for a long time. I know what it does and I know what it doesn't do. I'd still need to go find a status page. I still need to go find something that integrates better with Slack. From a functional perspective, it just didn't make sense. PagerDuty could page people. But it couldn't provide a status page, and it didn't integrate natively with Slack. Buying PagerDuty meant also buying a separate status page product, then gluing them together with custom integrations. For a support team that needed to move fast during customer escalations, stitching tools together wasn't a plan, it was a liability. **Security needed an incident process built from scratch. And it couldn't look like an SRE runbook.** Jonathon Klobucar, known as JK, was Sublime's first security engineering hire. He came from an SRE background and had a chance to build the entire security incident process from scratch. His initial plan was document-based tracking, workflow automations, and PagerDuty for paging. PagerDuty could page the right people. But JK needed more than that: a workflow for structured, multi-day investigations that could handle sensitive access controls and keep security work contained. > PagerDuty does not have a great incident management platform. It's good at paging and reporting. But as far as an actual incident workflow, I never found it particularly useful. Security incidents are fundamentally different from engineering outages. They're investigative, longer-tailed, and sensitive by default. A security incident might run for days or weeks. Access needs to be tightly controlled. **Engineering was tired of maintaining the workaround.** Steven Edouard, Engineering Manager on the backend and infrastructure team, had built Sublime's incident process himself: a Slack channel creator wired to a project management tool through a homegrown automation layer. It worked. Until it didn't. > I'm frustrated and tired. As a manager, I don't have time to deal with automations that keep breaking. There are three or four products out there that just do this. When something broke, the team would spin up a channel, try to loop in the right people, and hope the automations held. Getting the right person's attention meant adding their name to a channel and hoping they were online. With no formal paging in place, getting the right person's attention meant adding their name to a channel and hoping they were online. The overhead of maintaining a fragile homegrown system wore him down. --- ## The solution ### The procurement story nobody planned The path to [incident.io](http://incident.io) at Sublime Security wasn't a top-down decision. It was a series of collisions. Support found the product first. Korey evaluated it, liked it, and tried to buy it. But the purchase got stuck in procurement, specifically in the third-party risk management process. JK, sitting on the security side, noticed the active evaluation. Then he realized something: the TPRM process blocking the purchase was his process. He owned it. He'd been independently looking for a security incident platform, and here was one already being evaluated by another team. > I went to the CISO and said: we're going with this. I think this is the best-in-class solution for us. JK championed the purchase to the CISO and unblocked procurement. Security and support went live on [incident.io](http://incident.io). The initial contract covered 15 seats. Word spread to engineering. > Engineering saw how support was running incidents and didn't need to be convinced. They started using it immediately and became heavy users quickly. Engineering had channels, coordination, and automations in place. Paging was the one gap. Rather than filling it with PagerDuty and moving on, Steven saw what support and security had and wanted the same. > We've got to get this. It will actually make my life a lot easier. Fifteen licenses became 90. Nobody mandated it. Nobody ran a formal rollout. Three teams, each solving their own problem, converged on the same platform because it was the one that actually worked. > incident.io was adopted by more teams than we expected. We started with 15 seats and now we're at 90. Adoption was fast because everything integrated well. ### How it works today Each team uses [incident.io](http://incident.io) differently, but the platform is the same. Support runs on-call rotations that account for multiple time zones. A Pylon integration triggers incidents automatically when customers reach out through specific channels. The phone tree is wired directly into the platform: when a customer calls the support number and presses option two, it pages someone in [incident.io](http://incident.io), triggers an incident, opens a Slack channel, and creates a support ticket. > If a customer clicks option two, it pages somebody in incident.io and that triggers an incident, pings people in Slack, immediately opens a support ticket. That would be a tremendous amount of effort otherwise. All I did in incident.io was: go to this number, set up a workflow. Done. Security applies incident command structure to investigations. When an incident goes active, the security rotation gets paged. Private channels keep sensitive investigations contained. The Linear integration feeds follow-up actions directly into JK's team's project management tool, keeping security work tracked without context-switching into a separate system. Engineering now has clear escalation paths. The engineering incident lead gets paged first, triages the issue, and escalates to the right team. The coordination between all three functions is defined, not improvised. > The coordination path between security, support, and engineering is better than before. There are clear paths to escalations. We never used to have that. Korey has become an unofficial internal evangelist. When engineering teams reach for a workflow tool to automate something, he redirects them. > Don't build another automation for this, just use incident.io. I can show you the one I already made. --- ## The impact ### Reporting that used to take hours now takes minutes Before [incident.io](http://incident.io), generating incident reports was a manual exercise. Korey would calculate durations by hand, converting UTC timestamps to local time zones, cross-referencing Slack messages with ticket logs. A single report could take four hours or more. ### A security incident process that didn't exist before JK had a blank slate. He could have spent months building a custom system out of document tools, workflow automations, and PagerDuty. Instead, he had a structured security incident workflow running in weeks. The incident command model that [incident.io](http://incident.io) brings from SRE practice translated directly to security operations. > incident.io is doing a good job of being built with SREs in mind, using those principles, but it's very accessible to other fields, like security. ### Engineering stopped maintaining its own infrastructure Steven's homegrown system is retired. No more broken automations. No more hoping someone sees their name in a channel. Engineering has formal paging, structured escalation paths, and a coordination layer that connects them to support and security when incidents cross team boundaries. > It's leaps and bounds better. There's a lot of value, and I want to make sure you all know that. ### A tool that keeps finding new uses The clearest sign a tool is working is when people start using it for things it wasn't originally bought for. At Sublime, that's exactly what happened. > It's probably the least painful tool I've set up in a long time. It just continues to do what I need it to do. And I've started using it for more things than it's probably supposed to be for, but it just keeps performing. JK is watching [incident.io](http://incident.io)'s AI capabilities closely. With MCP and Claude integration now available, he sees potential for automated correlation across security incidents, reducing the investigative burden on a team that's still growing. For now, the platform continues to expand the way it arrived: organically, team by team, because it solves the problem in front of them better than anything else they've tried.