In this episode, Sean is roleplaying the CISO at It’s Electric, when he gets an interesting call.
VideoSecurity
August 5, 2026

Sean Cassidy, CISO at Plaid, and the moving mouse | The Tabletop

Written by
Sarah Cottone
Sr. Content Marketing Manager
Reviewed by
No items found.

Accelerating security solutions for small businesses 

Tagore offers strategic services to small businesses. 

A partnership that can scale 

Tagore prioritized finding a managed compliance partner with an established product, dedicated support team, and rapid release rate.

Standing out from competitors

Tagore's partnership with Vanta enhances its strategic focus and deepens client value, creating differentiation in a competitive market.

Watch all episodes from The Tabletop on YouTube.

Episode description

You’re a CISO at “It’s Electric,” and you get an interesting call. A local power plant operator just watched his computer mouse move on its own…should he be worried? In this episode of The Tabletop, Sean Cassidy takes the hot seat and works the problem in real time.

Sean is an engineer who became a security leader. He started as a software engineer building firewalls at Cisco, co-founded the security company DefenseStorm, led information security at Patreon, and spent nearly seven years building the security function at Asana. He recently landed at Plaid, a company sitting at the intersection of consumers, financial institutions, and increasingly AI agents making financial decisions on their own. 

In this episode, host Khush Kashyap drops Sean into the following scenario: He is roleplaying the CISO at It’s Electric, a 10,000-employee utility serving customers across the country. Mid-morning on a Tuesday, a floor operator named Mike calls. His mouse started moving on its own, and by the time he grabbed the keyboard, someone had already been inside the plant’s control system and changed the configuration—changes that, left unchecked, could have cascaded into a wider power outage. 

Mike caught it manually. Then the logs widen the picture: not one compromised workstation, but three. They all trace back to a remote-access tool tied to a third-party vendor service account that was installed four years ago, never deprovisioned even though the contract expired 18 months ago, and now logging in from an IP address outside the US. Then a name surfaces: a former employee terminated six months ago whose shared credential still works.

Sean walks through scoping an OT incident with EDR and laptop forensics, why general counsel is his very first call, holding two theories at once (external actor versus insider) rather than betting early, when to pull in law enforcement, what belongs in a public holding statement, and the NERC CIP compliance exposure sitting underneath it all. Along the way, he makes the case that the real failure happened long before the incident, in the vendor and employee offboarding that nobody owns. At the end, he renders his verdict: real incident or constructed fiction?

Quotes

“This is where my mind goes from, ‘It could just be a Mike problem,’ to, oh, no, this is a real security incident.”

“General counsel is always my partner in crime. Or not crime - partner in doing it right.”

“When you’re terminating a relationship, nothing breaks if you don’t do anything. You don’t notice.”

“Usually it’s no one’s job to make sure vendors are turned off.”

“IT playbooks are really good for common events. A mouse moving on its own? That’s not in the playbook.”

Time Stamps

[00:00] Welcome to The Tabletop: Meet Sean Cassidy, CISO at Plaid

[00:18] The Rules: CISO at It's Electric, a 10,000-Person Utility

[00:56] The Scenario: A Mouse Moves on Its Own at a Power Station

[01:18] Inject One - Technical Escalation: Not One Workstation, but Three

[03:13] Your Next 10 Minutes: Scoping the Incident and Paging Responders

[03:59] Why User Reports Take a Back Seat to Forensics

[06:09] The First Call: General Counsel Before the CEO

[06:59] Inject Two - Human and Reputational Pressure: A Dead Vendor Account and a Foreign IP

[08:11] Four Years Undiscovered: The Board Conversation You Should Have Had Sooner

[08:53] Nation-State or Not: How Much to Say Before Attribution

[10:05] The Compliance Clock: NERC CIP Supply Chain and Remote Access

[11:00] The Twist: Your General Counsel Is Unreachable

[12:04] Inject Three - Values Tradeoff: A Former Employee's Name Surfaces

[12:48] Telling the CEO: Outside Attack or Inside Job?

[14:02] Law Enforcement Timing: The Cost of Moving Too Early or Too Late

[16:02] What Goes in the Public Holding Statement

[17:23] Three Weeks Later: CISA, ISAC, and the NERC Reporting Threshold

[19:11] The Moment of Truth: Real Incident or Fiction?

[20:49] Off the Table: Why Vendor Access Never Gets Cleaned Up, the OT Playbook Gap, and the Database That Vanished

Transcript

Khush: Hi, I'm Khush Kashyap, senior director of GRC at Vanta and your host for this Tabletop. Our guest today is Sean Cassidy. Sean is an engineer who became a security leader. He started as a software engineer working on firewalls at Cisco, then founded his own security company, led security at Patreon, and eventually built the security function at Asana.

After nearly seven years there, he recently landed at Plaid, a company sitting at the intersection of consumers, financial institutions, and increasingly AI agents making financial decisions autonomously. But today, Sean is in the hot seat playing CISO at It's Electric. 

Sean: I'm excited. 

Khush: So here are the rules for you, Sean.

You're now the CISO at It's [00:01:00] Electric. It's a 10,000 employee utility company serving customers across the country. A scenario unfolds with multiple injects. Sean will give his live reaction. At the end, he'll decide real incident or fiction. Sean, are you ready for the tabletop? 

Sean: I'm ready.

Khush: Here's the scenario: It's mid-morning on a Tuesday. You get a call from Mike, one of the floor operators at a local power station. He was watching his workstation when the mouse started moving on its own. He grabbed the keyboard, but by the time he took control, he could see that someone had been inside the plant's control system, and they had changed the configuration.

Mike corrected them manually before any downstream impacts could happen. If they would run unchecked, the changes could have disabled the protection, stopping a fault from cascading into a wider outage. Mike wants to know, should he be worried? 

Sean: Uh, yeah, I think so. I think it's a very reasonable thing to be worried about.

I would probably, because he's on the phone with me, ask him, like, "Did you install any, like, remote desktop? Uh, you know, did, did somebody... Did you need help with your computer recently, and you contacted who you thought was IT?" It's a very common attack vector. I'd probably ask him, like, those kinds of questions. But yeah, I think, I think this is very reasonable to be worried about this. 

Khush: While you're on the phone with Mike, your IT lead pings you with a log pull. It's not one compromised workstation, it's actually three. 

Sean: Mm-hmm. 

Khush: The same remote access tool is showing active or recently active sessions on two other controlled terminals in different locations. Mike's station was the only one where changes were made, but you don't know what was accessed on the others. 

Sean: Yeah, this is where my mind goes from, "This could be an isolated incident. It could just be a Mike problem," and to now it's like, oh, no, this is a real security incident. This is... Now we need to spin up all of the things.

You know, I don't have 100% confirmation of this, but I, [00:03:00] I, I trust my, uh, IT people. And I would be like, "Okay, great. Whatever button we need to press to initiate security incident response, that's what we're going to do." Probably the first order of business is to try and see what, see what's happening. 

Khush: What would your next 10 minutes look like?

Sean: Uh, the next 10 minutes would probably be starting that process. Paging the people who need to be paged. Is it corporate security or IT security? Trying to make sure we can understand and we can get this, like, right scope for it. For example, like, can we, on our EDR, can we fully understand how many of these are happening?

Is, is it three or is it 3,000? Just because it's three doesn't mean it's not severe, but, um, that can help, like, scope the, scope the problem. But yeah, really trying to get all of the right incident responders online looking at this is, like, my, my most important next step. 

Khush: So Mike isn't sure how long the session was running before he noticed. Does the uncertainty about the window change how you respond? 

Sean: At this point, user [00:04:00] reports aren't that important to me. Like, we're gonna use our laptop forensics and our tooling more than user reports. It's, it, it's interesting that he doesn't know. Like, it wasn't a v- very clearly defined, "I did this thing and then there was a problem."

But, um, I don't think that I would use that as, like, a primary piece of evidence here. It's, we're gonna hand it over to the incident responders. We're gonna, like, do laptop forensics. 

Khush: You mentioned one thing briefly before where you said that now that you are aware that there were three more systems, it does seem like a security incident. One thing that I want to ask you is, if the changes were corrected before anything reached the public or any downstream implications did make their way, does that affect whether you treat this as an active incident, especially with two other terminals unaccounted for? 

Sean: Uh, this is definitely gonna be a, a security incident no matter what. Definitely would not just try to sweep it under the rug and say, "Oh, oh, the attacker didn't do anything. Great. I'm gonna go back to the beach," or whatever the thing is. Uh, um, no, this is a real important thing that we need to look into. We can't, uh, sweep this under the rug or kind of s- say like, "Oh, nothing bad happened, therefore we don't have to investigate."

Khush: One last question before we go into our next inject is- Mike is a floor operator. He's not IT. What do you need from him right now that he may not know how to give to you? 

Sean: Uh, I would like to know, like, his last few hours. Like, like, is like, still the source of this is unknown at the moment, right? So was there some social engineering going on? Did something happen? He click on a particular email? Was he looking for help, uh, for an IT issue and he thought he reached out to its electric IT, but he reached out to some other one, some other watering hole type attack? Um, that kind of narrative would be very important. Um, he might not know how to give that to me.

Sometimes people's personal accounts can be kind of confused, right? Um, but I, I would love to know like from his perspective what happened, what, what went [00:06:00] wrong and when. 

Khush: Your quick call within the first 30 minutes, who are you speed dialing first, the CEO or the lawyer? 

Sean: Uh, general counsel first. Uh, general counsel is always my partner in crime or not crime Partner in, uh, doing it right. Mm. That is the first person I would call, uh, our legal contact or general counsel or both. Um, and we would be sharing up to the minute, uh, details about what happened or what didn't happen. Um, and I like working with the general counsel because not only is their job to protect the company and they're fantastic about it, we can establish attorney-client privilege early if necessary, and they're very used to dealing with the level of uncertainty, whereas sometimes CEOs can react in different ways. Like they could overreact or under-react. Uh, whereas like a general counsel is like, you know, usually a very reliable partner.

Khush: Here is your second inject. After digging in, here's what the logs show. The changes were executed using valid credentials. A service account tied to a third-party vendor that installed a remote access tool about four years ago for routine maintenance support. All three sessions trace back to the same vendor service account.

You see the tool is still active, and the account was never deprovisioned, even though the vendor contract expired 18 months ago One more detail. The session originated from an IP address outside the US. What do you do next? 

Sean: I think the most important thing to do next is probably disable that tool. So I probably...W- we're gonna do a few concurrent streams here. We're gonna spin up one work stream that's like, turn that off everywhere. Every single place we can, we're gonna turn that off. And then the other side is going to be, we're going to start investigating what happened, what did they do. Is it really only three? Is it more than that? And then we're gonna see, uh, what they started to do. Uh, the fact that it's outside the US is i- interesting, right? Lots of threat actors are outside the US. Um, but, uh, I, I really wanna know what happened, and I wanna stop the bleeding. 

Khush: The remote access tool has been running undiscovered for four years. Does that tell you anything about your security program and visibility program? Is this the kind of conversation you need to have with your board? 

Sean: Uh, yes. Uh, I would probably say ideally this would've been a great conversation to have prior to the incident, uh, that we don't have a full accounting of our software inventory, that we don't know what's running, that we don't have a full list of all of our vendors. I think that would've been a great conversation to have 6, 12 months ago. But now that this has happened, we have to talk about it, um, and that this would absolutely be a top risk in our risk register. We would absolutely be talking to the board or executive committee about it, and ha- uh, talking about how we handle vendor contracts, vendor off-boarding, make sure our employee off-boarding is top-notch, all of that.

Khush: The session originated from a foreign IP, but attribution isn't confirmed yet. So are you going to lead with a possible nation state actor in your internal briefing, or are you sitting on that detail until you're more certain? How are you thinking about the risk of each? 

Sean: This is where I would, uh, lean on my legal counterpart a little bit, uh, because i- once it's out, once it's outside, I wanna start the process of law enforcement. We might need to involve law enforcement here. Uh, this could be a sophisticated attack where they want to do a lot of harm to the company, and I want our, my legal counterpart to start that up. I don't wanna start speculating who exactly it is just yet. Um, it's honestly... It... That, that's not gonna be critical right now.

That can be critical later on in the investigation. After we've closed off all of the low-hanging fruit, it's nice to do a little bit of attribution to do, uh, some kind of mapping to make sure that, uh, we understand the TTPs, right? The e- exact techniques and tactics that each threat actor will use to make sure that we've fully remediated the incident, but that's later on. That's not right now. 

Khush: I want to touch upon the compliance aspects a little bit So the vendor account that was never deprovisioned, that's a NERC CIP 013 supply chain failure. There is also a CIP 005 remote access failure. Knowing there is a potential compliance violation on the table, does that change how you sequence your response, or is that a next week or a later problem?

Sean: I think that's a next week problem. It's not a super late problem. It's not like we'll, we'll revisit this in six months, but next week is going to be when we... When we're done with the really acute problem, like, okay, we've locked down these accounts, we've understood this, there might be problems with other vendors and other software, and it might actually be the exact same scenario again and again and again, vendor proliferation and such that there might be several remote access tools or similar type things. But that's not gonna happen today. That's gonna happen next week. 

Khush: Before you answer the next inject, this is the twist. I'm sorry to say your general counsel is unreachable. 

Sean: Oh, great. 

Khush: They are on a transatlantic flight, and the Wi-Fi isn't working. Guess they don't have Starlink yet. To make matters worse, your outside legal firm is in a conflict, hold on related utility matter. Basically, you have no legal counsel available for the next twenty-four hours. Everything you decide from here is something you own. 

Sean: Okay. 

Khush: How are you feeling about it? 

Sean: Uh, not great. I wish the... We should have, uh, done some business continuity planning here. Uh, but we just gotta roll with it, right? So obviously, we can't make this whole incident attorney-client privileged.

There's no attorney present. Uh, and we can't get legal advice. We're just going to do the best we can to remediate this without legal help. Hopefully, we have some kind of, like, incident response retainer. We can maybe set that up, right? So we can have some external help, uh, from some, uh, forensics firm. Uh, but yeah, not, not feeling great about  not having my legal partner.

Khush: Here is your inject three. This is what's next. A name has surfaced. Your team pulls the account history, and the person who originally set up that vendor's remote access account using a shared credential that nobody ever rotated is a former employee. They were terminated six months ago. Their internal IT access was killed on day one of their termination, but that login still works, and it's still in their name.

So now you're looking at two theories. One is an external actor got hold of the vendor credentials, or second, someone who used to be inside is responsible. One path is a cyber incident, the other is a named individual that r- would require HR, possibly law enforcement, a different set of obligations. Your CEO is waiting, and they want to know if this is an outside attack or an inside job.

What do you tell them? 

Sean: I don't view these, like, wildly different. I view these as pretty similar. Uh, this person who doesn't work here anymore is an outsider to the company, and, uh, it, it just probably a different motivation, right? They might have an ax to grind or something like that. And the, the law enforcement angle changes then, right?

If this person is in the US versus, uh, kind of a nation-state attacker. Uh, but the incident response itself is going to just assume that they're an adversary to us. Doesn't matter who or why. Uh, I really like having two separate theories. I lo- I love having, like, working theories that we can prove or disprove, we can gather evidence for or, or against.

And I would encourage the team to try to keep these two theories alive and try to see which one seems to be more true. Uh, was there a certain time of day activity that implies one over the other? Certain tactics that were used that implies one or the other. Um, and that will obviously affect our remediation steps, our post-incident action items, depending on which one it turns out to be. But, uh, yeah, I, I, I would treat these as, like, at least in the early incident, these are the same thing. 

Khush: Got it. You do have a name tied to that account. At what point do you share it with the CEO before attribution is confirmed? 

Sean: It would depend on my relationship with the CEO. Mm. Um, I think if we were close partners, I wouldn't mind saying like, "Hey, we have some theories here." Uh, because that would signal that we are working hard and diligently. Um, but if we were kinda a little more arm's length, I might keep that a little closer for a little while and wait till I have more certainty here. Um, because I, I really don't wanna put an individual in the spotlight if they're innocent here. Uh, I would like to have a little bit more information before I, b- before I do that. And, and there will be time to, to do that. Like, if, if legal action needs to be taken, like, that, that won't happen today. 

Khush: Mm-hmm. You mentioned that you would treat both the scenarios and both the working theories pretty similarly from an incident remediation perspective. So if you do escalate to law enforcement prematurely and it's an, an external at- actor, what's the  exposure? And if you wait, and it was a former employee, what did you miss? 

Sean: Yeah. Great, great, great question. Um, if we wait and it's a former employee, that can really result in some negative outcomes for law enforcement. This person might have left the country or is hard to get. Key evidence might be lost. They might delete things. They might realize that they're ... you know, we're, we're onto them kind of thing. Um, so law enforcement early on the named person version is, is, is important. On the external one, I actually like having law enforcement in early because they are actually a really helpful source for, um, like attribution.

Like they ... Like, this seems similar to other attacks that they've seen. They have a very wide view on these things. Um, so we typically like to involve them early if this is a real incident. I think where it gets expensive to involve them is if it's not real yet. Like, if you don't know, if you have a suspicion something might be wrong. Um, but if something's wrong and damage has happened, absolutely involve law enforcement. 

Khush: Does the uncertainty around attribution changes what goes into public holding statement, or does it matter at this stage? 

Sean: Uh, how far are we into the response? 

Khush: Uh, we're still in week one. 

Sean: We're still in week one? 

Khush: Yeah.

Sean: We don't need to publicly give attribution just yet. Um, that, that will come in the weeks and months ahead. And I think especially when you're having public statements, it's expensive to get this wrong. Mm. Um, and it can be kind of embarrassing if you're like, "Hey, this is a very severe nation state actor, and we it's super sophisticated." And it turns out it wasn't. It turns out it was a password that wasn't rotated from a former employee. It can be embarrassing to walk that back. And vice versa, if you name the employee and it turns out it was a nation state attacker, like that's a, that, that's a big deal, right?

So once we have a lot of certainty around this, then we can go public with a theory on attribution. And the real reason to have some kind of public communication about this is, like, obligations to customers, partners, uh, other, other vendors. And, uh, usually they don't need attribution early. They need to know what they need to do, what information was compromised, that that's what they wanna know 

Khush: That sounds good. Especially this is a utility company, so the government may get involved as well. 

Sean: Correct. 

Khush: Okay, Sean, so you can take a deep breath now. Whew. We are fast-forwarding three weeks. 

Sean: Okay. 

Khush: Access points have been closed. The investigation is ongoing. A preliminary report has been drafted for CISA and ISAC, and your team is assessing whether this meets the threshold for a mandatory NERC reportable incident filing or not. Looking back at the full arc, the dormant vendor account, the legacy tool, the operator who witnessed the mouse move, what was the single decision or non-decision that put It's Electric on this path?

 

Sean: I think the, the decision here, uh, or, or, or like the, the process that went wrong is the, uh, vendor management off-boarding/e-employee off-boarding. Like, rotating those credentials, off-boarding vendors, it's a very common thing to forget and to miss, uh, because when you're terminating a relationship, nothing breaks if you don't do anything. It actually... You don't notice. Whereas when you're on-boarding a vendor, there's all this stuff you need to do to set them up, right?

Um, but when you're turning them off, that's the time you actually need to do this. So that's the kind of key thing that was missed here, uh, and that's really going to be, like, going forward, a big part of the changes to the security program is, like, an inventory of which vendors are doing what. Uh, are they active?

Are they being decommissioned? Is that decommission work finished? Uh, all of those things. Uh, and also should actually be involved in our security assessments, our penetration tests of, like, assessing this stuff. Are there old remote access tools? Are there old VPNs set up that we need to take down? That, that sort of thing.

Khush: That makes sense. Got it. Especially when it comes to critical infrastructure and- Yes ... all the access and application security that goes into it. So here is the moment of truth. Sean, I have one last question for you about this incident. You have been in the hot seat tracing a mouse that moved on its own, hunting down a vendor account nobody remembered to close, and making calls without a general counsel in your corner. Does this feel like something that has actually happened, or is it something we invented?

Sean: I feel like this... There, there, there's a lot of realistic things here. This could have happened, so yeah, I'll, I'll go with, uh, it happened. 

Khush: So if we were to ask you for your final answer, is this scenario real or fiction? 

Sean: I'm gonna say real. 

Khush: Real. Here is what I'll say. In 2021, an operator at a water treatment plant in Oldsmar, Florida, watched his mouse move on its own and caught someone pushing chemical levels dangerously high. It's the same story we walked through today. A vendor remote access tool left running for years with one alert human as the last line of defense. But then the real incident got really strange because the FBI reportedly couldn't confirm anyone broke in at all. Oldsmar's own city manager later called it a non-event and most likely operator error.

So real or fiction, we won't know, but the scenario we walked through today is based on real e- events. And the real event itself, the one that put OT or operational technology security on the front page, they got cited in congressional briefings that reshaped how the industry thinks about vendor access and remote tools, um, may never have been an attack at all.

Sean: Wow.

Khush: Let's do a quick round of Off the Table, our opportunity to get off-the-cuff answers on big security questions. 

What's the single most common reason vendor access [00:21:00] never gets cleaned up after a contract ends? 

Sean: Uh, I think it's what I said earlier in that, uh, when you turn off a vendor, like, you don't have to turn it off, right? Like, it... Everything keeps working, you just don't pay the bill anymore, and some- sometimes things just keep working. Like, that's the key reason, right? And usually it's no one's job to make sure vendors are turned off. 

Khush: When is the moment in an OT incident when most organizations realize their IT playbook doesn't apply?

Sean: IT playbooks are really good for common events, right? Of like, oh, this happens 10 times a day, right? Uh, and those uncommon events like mouse moving on your own perhaps, like very rare to happen, uh, that's not in the playbook, right? You don't know exactly what to do. This has never happened before, and that's...You need to think on your feet and see what's, see what's going on. 

Khush: Yeah, it's hard to attribute something like that to, like, a system failure or a bug. 

Sean: Yeah, it's true. 

Khush: Mm. What's one thing you would require of every third-party vendor before they touch an operational system? 

Sean: Uh, I would say the one thing I would require is that they need to have identity and access management firmly handled. This is single sign-on. This is SAML. This is automated provisioning and deprovisioning. That stuff is so important. It may have affected this one because if it was automatically turned off, this might n- whole incident might not have happened. 

Khush: Mm. Every security leader has one incident that still makes them shake their head, something strange, unexpected, or almost too absurd to believe. What's yours, if you can share? 

Sean: A previous company I worked at had, uh, like many companies, lots of developers, had, uh, lots of access to production, and one day the production database went missing, and when I say went missing, it just wasn't there anymore. And we were wondering what happened, and one of the engineers accidentally deleted the database.

And you might be like, "How could an engineer accidentally delete the database?" But it was, uh, the case of startups moving quickly, and this... We actually at first thought it was some kind of hacker going on because, like, it's such an extreme action to take to delete an entire database, and it's not in any engineer's normal playbook to do. Uh, but it was literally just an accident. It was a, it was a script error, and we spent a decent amount of time trying to recover from that. Luckily, we had some backups, minimal data loss, but that one always sticks in my mind because it's like, yeah, that was just very painful. 

Khush: Wow. Are we talking about days and weeks of security team's time spent on figuring it out, or?

Sean: This was, uh, several hours, maybe like- Mm ... a day and a half of trying, trying to figure this out, uh, because we were worried that, uh, what if we spun up the database, put it back on, but they just took it down again. Like, if they have access and they're turning things off, like, could this just keep happening? Yeah. Luckily, it was kind of an insider accidental type thing. 

Khush: Gosh, I just hope that it didn't happen on a holiday or during the weekend. 

Sean: Luckily, it was during normal working hours. 

Khush: Amazing. Um, last question: Anything else that we didn't cover in our conversation today about this incident? 

Sean: There's so many interesting things with things like this, uh, like laptop forensics, uh, and like logging and EDR. Like I think that could have really, really helped here, like exactly what connections were being made. 'Cause if we had evidence of the remote access tool being used, we could really determine whether or not this was like a, a, an actor in the water plant, or if it was, you know, operator error. Then the other thing too is it sounds like there was probably some training misses here. Mm. And I think training key personnel here on how to spot suspicious behavior and report this stuff. Like, glad he called me, but actually, actually probably not the right way to report security incidents. Yeah. Sometimes I'm busy. Uh, but really, really training would be an, a massive help here. 

Khush: That makes sense. And we think about these control systems, like the SCADA system, as like [00:25:00] truly OT and truly like manufacturing and technology and IT coming together. But we forget like the security aspects and, um, all those different controls which come together, thanks to NORC and SIP and everything else that the government has done in this space.

All right, Sean, you survived the tabletop. Thank you so much for being here. 

Sean: Thanks for having me.

Access Review Stage Content / Functionality
Across all stages
  • Easily create and save a new access review at a point in time
  • View detailed audit evidence of historical access reviews
Setup access review procedures
  • Define a global access review procedure that stakeholders can follow, ensuring consistency and mitigation of human error in reviews
  • Set your access review frequency (monthly, quarterly, etc.) and working period/deadlines
Consolidate account access data from systems
  • Integrate systems using dozens of pre-built integrations, or “connectors”. System account and HRIS data is pulled into Vanta.
  • Upcoming integrations include Zoom and Intercom (account access), and Personio (HRIS)
  • Upload access files from non-integrated systems
  • View and select systems in-scope for the review
Review, approve, and deny user access
  • Select the appropriate systems reviewer and due date
  • Get automatic notifications and reminders to systems reviewer of deadlines
  • Automatic flagging of “risky” employee accounts that have been terminated or switched departments
  • Intuitive interface to see all accounts with access, account accept/deny buttons, and notes section
  • Track progress of individual systems access reviews and see accounts that need to be removed or have access modified
  • Bulk sort, filter, and alter accounts based on account roles and employee title
Assign remediation tasks to system owners
  • Built-in remediation workflow for reviewers to request access changes and for admin to view and manage requests
  • Optional task tracker integration to create tickets for any access changes and provide visibility to the status of tickets and remediation
Verify changes to access
  • Focused view of accounts flagged for access changes for easy tracking and management
  • Automated evidence of remediation completion displayed for integrated systems
  • Manual evidence of remediation can be uploaded for non-integrated systems
Report and re-evaluate results
  • Auditor can log into Vanta to see history of all completed access reviews
  • Internals can see status of reviews in progress and also historical review detail
FEATURED VANTA RESOURCE

The ultimate guide to scaling your compliance program

Learn how to scale, manage, and optimize alongside your business goals.