In this episode, Gabor Sivók, Cloud Security Architect at Queue-it, shares a practical look at what it takes to secure large-scale systems in today’s cloud environments. He walks through Queue-it’s journey to ISO 27001 certification, the real trade-offs between security and performance, and how security practices adapt in multi-cloud setups. Gabor also weighs in on the growing role of AI in security operations—and why the best security work often stays invisible. A grounded conversation for anyone working at the intersection of reliability, scalability, and security.
Gabor Sivók is a Cloud Security Architect at Queue-it, where he leads security efforts across the R&D organization. With a background in infrastructure and compliance, he played a key role in Queue-it’s ISO 27001 certification and now focuses on securing multi-cloud environments at scale. Gabor works closely with platform engineering teams to embed security into architecture decisions while balancing performance, resilience, and risk. He’s also an active participant in the security community, keeping pace with emerging threats and tooling through Discord, Reddit, and bug bounty networks.
Episode transcript:
Jose
Hello and welcome to the Smooth Scaling Podcast, where we're speaking with industry experts to uncover how to design, build, and run resilient and scalable systems. I'm your host, José Quaresma, and today I'm joined by Gabor Sivók, a cloud security architect at Queue-it.
It was a very insightful conversation about security considerations and implementations in the cloud world. I especially enjoyed discussing the challenges and trade-offs when developing for resilience and high scalability with security in mind as well. Enjoy.
Welcome, Gabor. It's great having you here.
Gabor
Thank you for having me.
Jose
I think it's super interesting with security because the impact is huge, right? And the commercial impact of a lack of security is also huge.
We have these numbers from the Cost of Downtime report from Splunk last year, putting a number on the losses among Global 2000 companies—about $400 billion a year lost due to downtime. And according to that report, I think about 56% of that is related to cybersecurity.
At the same time, security—if done well—is invisible. If you and the team are doing it right, we almost don't talk about it, because things are going well.
So it's great to have you here to share a bit more about what you do every day, what it looks like—so we can also highlight the work that’s often done in the shadows.
You're a cloud security architect here at Queue-it. Can you tell us a little bit about your responsibilities? What does your day-to-day look like?
Gabor
I'm part of the Architecture, Security, and Quality team, and I'm responsible for every security-related task within the R&D organization. So, you name it—from monitoring and investigation to architecture review—everything. It's a broad role, being a security architect at Queue-it.
Jose
Is there any example that comes to mind of some of the latest activities? I know you probably can't share full details, but is there something—a specific day or a particular kind of activity—you found interesting, that maybe gives us a look into what that work is like?
Gabor
Well, in the past couple of days, my mind was on the podcast, so I was gathering information for that.
But we had a GameDay yesterday, organized by AWS. It was focused on security, and it was something we did as the whole R&D organization. We had nine teams, and we were basically competing against each other by solving security-related tasks within AWS.
That brought up a lot of things I’ve done over the past couple of years in securing our infrastructure. It was a really nice, gamified activity showing how security should be implemented and embedded into the infrastructure and daily automations and jobs.
Jose
One follow-up question, maybe around the security part—because when I think about what you do and the security work, I often see, at least in my mind—and you can correct or confirm this—two areas.
There’s platform security, right? That’s part of your work from an architectural perspective, the cloud setup, and the security around that.
And then there’s also the other work, more around internal IT security—do we have the right tools in place, are people trained, etc.
Can you quantify how much of your time is spent on each? Is it 50/50 between platform and infrastructure security, and—I'm not sure what to call the other one—maybe IT admin security?
Gabor
I can tell you exactly, because it was very different back in the day when I started—almost four years ago.
Back then, IT was a one-person team, security was also a one-person team, and we belonged under the same organization. So we essentially worked together to solve both IT-related and infrastructure-related security. That was me, but I also handled the IT side.
Nowadays, IT has grown significantly, and they have their own dedicated person for security. So my involvement is less and less—almost zero. I’m trying to stay out of the IT side now.
Jose
Now that we’re talking about both the InfoSec side of things—thank you for putting a good word to it, I was trying to get to that word—and also the security around the platform and infrastructure, what comes to mind is the work we've been doing, and that you’ve been a part of, to get ISO 27001 certified.
Can you tell us a little bit about that journey and what it was like?
Gabor
It was a long journey. It started about two years ago when the company shifted focus toward enterprise customers.
Enterprise customers, of course, require stricter security—and proof of it. So they conduct constant vendor assessments. Initially, we received a lot of vendor questionnaires—security questionnaires—which, obviously, landed on my desk.
It was my job to fill out endless questions and answers. And we quickly noticed one thing: the first question was always, “Do you have any certifications—ISO 27001, SOC 2,” or something like that.
Whenever it was an online questionnaire and we answered “no,” an additional hundred questions would pop up. It was so annoying.
We realized there had to be a better way. Not just for our customers, but for ourselves. Even though we already had a lot of processes, procedures, and security controls in place, we had to prove it somehow.
So that’s how the whole journey started.
This summer, we finally achieved ISO 27001.
And going from me personally filling out those security questionnaires, we now have a dedicated compliance person, a larger IT team, and a dedicated compliance team.
We’ve grown a lot and matured in terms of compliance, audits, and IT security—if I can put it that way.
Jose
Yeah, it was a long journey. I think it’s great to have this both as proof that we take security seriously, and also as a forcing function—it pushes us to stay up to date and compliant.
It has benefits from different angles, I’d say. So it’s very good, and we’re really proud to have gotten there.
And thank you for your work.
Security, right—on this podcast, we often talk about reliability and scalability. I'd love to ask you how you see the intersection—how security decisions might impact resilience and scalability.
Gabor
Yeah, it's a good question.
If we consider discussions with the platform engineering teams—who are responsible for our infrastructure scalability—and the security discussions, sometimes it comes up that we need to implement a certain security feature, or we have to do something in a specific way, and that could compromise scalability or speed.
So architectural decisions are always impacted by the security controls we have.
Thankfully, most of the time we can come to an agreement. It’s not hard, because the platform engineering teams also have a really good security mindset, which helps us avoid conflicts.
But there are certain things we cannot sacrifice in terms of reliability, scalability, or speed versus security.
Cryptographic implementations, for example—we can’t go below a certain standard. That’s not just about compliance; it’s also a requirement from our customers and from ourselves.
One recurring topic is TLS. It constantly comes up. I’m a bit flexible on that one because it's a really important topic, but due to the large number of visitors we have, we have to take into consideration support for older clients.
We can’t just say, “From now on, we only support this cipher suite and that version of TLS,” because that would cut out a large number of our customers.
So we’re a bit more flexible in what we offer in terms of cipher suites or protocol versions. And that sometimes leads to arguments—between our customers, or in response to requirements that say we should have tighter controls around it.
But in the end, we want to provide the best possible service to everyone. It’s always a matter of balancing risk.
Jose
And we're talking TLS, and I’m not sure everyone knows what TLS is.
Gabor
When we're communicating with a website—from our computer to the website and back—it happens over a protocol called HTTP, or Hypertext Transfer Protocol.
But that’s not secure, because it’s a plain text protocol. To safeguard our communications, we put it over TLS, which is the secure protocol. That gives us HTTPS.
TLS stands for Transport Layer Security. It cryptographically encodes the communication between the client and the server.
There are certain cipher suites and protocol versions that are constantly evolving due to new weaknesses being discovered over time.
To exploit those weaknesses, attackers need access to significant resources and coordination. I'm not saying it's purely theoretical, but many attack vectors aren’t easily exploited.
You won’t typically see an exploit that targets a specific cipher version from someone’s home setup—it would require a lot of effort.
So that’s why, from a risk perspective, the probability and impact sit in a space where it still fits within our risk appetite.
Jose
I also wanted to touch on security and multi-cloud, right?
Multi-cloud is something we're starting to look into and move toward.
From a security perspective, has your work changed?
When you go from “this is the one cloud we work with” to “we have several cloud providers,” is that a fundamental shift in how you approach security? Or is it just more work added to your plate, without fundamentally changing the approach?
Gabor
It really depends on where the other cloud is located.
In our case, we’re partnering with another provider that’s not a fully managed service provider.
Coming from AWS—where we have all the managed services and integrated security controls like IAM, role-based access, and everything baked into the system—it’s very different.
With AWS, if we’re dealing with database security, we just do our part; the rest is owned by AWS.
But moving to a cloud where you have to manage your own services, build the entire pipeline, and figure everything out—because the same services don’t exist—adds not just complexity, but new challenges to our workflows, our architecture, and how we collaborate.
We already have something well-established. If we want to reuse that, we can’t—so we have to find new tools, new ways, and make it work.
Jose
When you're building those security mechanisms on the other cloud, are you trying to make it work the same way it does in AWS?
Or are you approaching it more from first principles—starting fresh and building what’s needed without referencing how it's done in the managed service?
Gabor
It's hard not to think about how we’ve already solved it and how we use it in AWS, because that’s a really convenient setup for us.
So, ideally, we’d like to mimic it in the long run. But we definitely have to come up with other solutions.
Because of that, we might need to change certain procedures, and there may be things we lack—either because we don’t have the capacity or because it doesn’t make sense to build them from scratch.
With managed services, things like configuration and the update process are handed off to AWS. We don’t have to deal with infrastructure or application-level tasks. That was so convenient.
Now, it’s something we really have to keep in mind.
Jose
Still within the cloud theme—a lot is happening in cloud security these days.
How do you see it in the future?
If we look a year or a year and a half ahead, what does good look like from your perspective?
Gabor
I don't know—I don’t really see the future.
But I can see some trends and changes over the past couple of years. It’s really hard to predict. Like, one year ago, if you had asked me what we could do with AI or what things would look like today, I wouldn’t have dreamt of where we are now.
AI has really sped things up. It’s already an integrated part of cloud services—it’s there.
But the question is how much we’re going to adopt it and how much we’re going to use it.
Right now, we’re still doing fine without fully relying on it. But as it becomes more embedded, especially in security and cloud, I think we’ll rely more on AI to handle certain tasks.
For example, it doesn’t make much sense to write a CloudFormation template by hand anymore, just to spin something up—or copy it from somewhere. Now, I just write the right prompt, and it’s ready for me.
So I feel like that’s where we’re headed.
Jose
Do you think that makes your security work easier or harder?
Are you optimistic about AI helping internally from a security perspective, or more pessimistic—like, we’re putting our faith in a non-deterministic system to help build our infrastructure?
Gabor
I think we have to find the right balance.
AI is a really good tool, and it’s helping us—but at the same time, threat actors are already using it, and they’ll keep implementing it more and more to come up with sophisticated attacks.
It’s endless—who comes up with the better solution first?
The threat actors will come up with a better attack, and then we follow that and try to build up defense mechanisms for the new vectors and threats.
And that game never finishes—thankfully not.
Jose
And that game never finishes.
Gabor
Thankfully not.
Jose
Yeah, for better and worse, I guess.
Very good—are you ready for some rapid-fire questions?
Gabor
Yes.
Jose
Is there any book, podcast, or thought leader you’d recommend to our audience?
Gabor
To be honest, I wouldn't specifically recommend anything.
I’d recommend checking out Reddit—there are a lot of great subreddits—and Discord channels.
I'm part of many Discord communities, though I can't always keep up with the volume of information.
I also listen to a few podcasts, mostly focused on bug bounty topics and new attack vectors—blogs, Reddit threads, that kind of thing.
So I wouldn’t highlight one particular source, but those are the channels I usually explore when looking for new insights.
Jose
Do you have any professional advice you’d give to your younger self—or to someone starting now in this career?
Gabor
That’s a hard one.
Well—not hard. I always say: start as early as possible to gain experience.
Go out and find a job while you're still in university, or even sooner.
That’s something I’d tell my younger self too—start as early as possible. It’s never too early.
Jose
Last question—to you, scalability is...
Gabor
I don’t have a definite answer to that.
But before I joined Queue-it, during the interview process, I was really skeptical. I kept asking: Why do people buy this solution? Why not just add more servers, more services, more CPU?
Now I know why.
To me, the company itself represents the answer—it’s not just about adding one more server or more RAM or CPU. It’s the whole idea of building something with the mindset of being able to scale, and being resilient to failure.
Jose
And I think we’ll wrap it up with that. Thank you so much for joining me.
Gabor
Thank you for having me.
Jose
And that’s it for this episode of the Smooth Scaling Podcast. Thank you so much for listening.
If you enjoyed it, consider subscribing—and maybe share it with a friend or colleague.
If you want to share any thoughts or comments with us, send them to smoothscaling@queue-it.com.
This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it—your virtual waiting room partner.
I’m your host, José Quaresma. Until next time—keep it smooth, keep it scalable.
[This transcript was generated using AI and may contain errors.]