What a Managed Security Function Looks Like in Practice

When people hear “managed security,” they usually think of a SOC that watches dashboards and sends alerts. That’s managed detection and response, and it’s one piece of the puzzle. But a managed security function is something broader. It’s outsourcing the entire security program: strategy, engineering, compliance, incident response, vendor management, and yes, monitoring too.

We run managed security functions for companies that need real security leadership and engineering but aren’t ready (or don’t want) to build a full internal team. Here’s what that actually looks like day to day.

Who This Is For

Not every company needs this model. It makes sense in specific situations.

You’re 50-300 employees with no dedicated security staff. You’ve been handling security ad hoc. Your CTO or VP of Engineering owns it by default, and it’s not getting the attention it needs. You know you have gaps but don’t have the expertise to prioritize them.

You need to pass a compliance audit. A customer is requiring SOC 2. Your cyber insurance renewal questionnaire is getting harder. A regulatory body is asking questions. You need someone who can own the compliance process end to end, not just fill out the questionnaire.

You tried hiring a security engineer and couldn’t. The security talent market is brutal. Senior security engineers command top-of-market salaries and are picky about where they work. For a non-security company, competing for that talent is hard. And a single hire still leaves you with no coverage during vacations, sick days, or turnover.

You had a security person who left. They built some things, documented some of it, and now nobody fully understands the security infrastructure. You need someone to pick up where they left off and actually maintain the program.

If any of these sound familiar, a managed function is worth considering.

How We Structure It

Our managed security function engagements typically involve two to four people from our side, depending on the client’s size and complexity. Here’s how the roles break down.

Security Lead (fractional CISO). This is the senior person who owns your security strategy. They set priorities, report to your leadership team, manage compliance efforts, and make risk decisions. They attend your leadership meetings (usually monthly) and are available for ad hoc decisions. This person typically spends 8-15 hours per week on your account, more during audit periods or incidents.

Security Engineer(s). These are the hands-on practitioners who implement and maintain security controls. They configure your cloud security posture, manage vulnerability scanning, tune detection rules, review infrastructure changes, and handle the daily operational work. Depending on your environment’s complexity, this is one or two engineers spending 20-30 hours per week on your account.

Compliance Analyst (when needed). For clients with active compliance requirements (SOC 2, HIPAA, FERPA, COPPA), we assign an analyst who manages evidence collection, policy documentation, vendor risk assessments, and auditor relationships. This role scales up during audit prep and scales down between cycles.

Each client gets a dedicated team. We don’t rotate people randomly. The same engineers work on your account week after week, and they build deep context on your environment. That continuity is the difference between a managed service that works and one that feels like calling a help desk.

What a Typical Week Looks Like

Monday starts with a 30-minute sync between our team and your engineering lead. We review the previous week’s security findings, discuss any upcoming infrastructure changes, and prioritize work for the week. This meeting is the primary coordination point and keeps everyone aligned.

Throughout the week, our engineers are doing hands-on work in your environment. That might look like:

• Reviewing a pull request that changes IAM policies or network configuration
• Investigating an alert from GuardDuty or your SIEM
• Tuning detection rules to reduce false positives
• Running a vulnerability scan and triaging the results
• Configuring a new security tool or integration
• Responding to a security questionnaire from one of your customers
• Updating a security policy document for compliance

We use your Slack (or Teams, or whatever you use). Our engineers are in your channels and respond during business hours. When something urgent comes up, you message us the same way you’d message an internal team member.

On Fridays, we send a weekly security summary. It covers findings addressed, open items, risk changes, and any recommendations for the following week. This is a short, structured document that your leadership can skim in five minutes.

What the Client Still Owns

This is important. Even with a managed security function, certain things remain the client’s responsibility.

Business risk decisions. We’ll tell you that a particular system has a critical vulnerability and recommend a fix. You decide whether to fix it now, accept the risk temporarily, or deprioritize it. We inform the decision. You make it.

Employee security behavior. We can set up phishing simulations, write security awareness training, and configure email security controls. But we can’t force your employees to follow security policies. That’s a management responsibility.

Budget allocation. We’ll recommend tools, services, and investments. You decide what to fund.

Access provisioning and HR integration. We’ll design and configure your access control framework, but your HR and IT teams need to handle the operational onboarding and offboarding process. We’ll set up automated deprovisioning where possible, but someone on your side needs to trigger the process when an employee leaves.

Incident decision-making. During an incident, we run the technical investigation and containment. But decisions about customer communication, legal engagement, and business continuity are yours. We’ll advise, but the final call belongs to your leadership.

The line is clear: we own the security program’s execution. You own the business decisions that security informs.

How Handoffs Work

Handoffs are where managed services typically fail. Here’s how we handle them.

Onboarding (weeks 1-4). We start with a comprehensive assessment of your current security posture. This covers cloud infrastructure, application security, access management, compliance gaps, and existing tools. We document everything in a shared security knowledge base that both our team and yours can access. By the end of week 4, we deliver a prioritized remediation roadmap and start executing against it.

Ongoing operations. All work is tracked in a shared project board (we use whatever tool you already use, whether that’s Jira, Linear, Asana, or GitHub Issues). Every change we make to your environment is documented, reviewed by someone on your team when appropriate, and logged. We don’t make changes in the dark.

Escalations. We have defined escalation paths for different scenarios. A critical vulnerability gets escalated to your engineering lead immediately. A compliance deadline gets escalated to your operations lead. An active incident activates the incident response plan, which we build during onboarding.

Offboarding or transition. If you decide to hire internally and bring security in-house, we run a structured transition. We document all active processes, train your new hire on the environment, and provide 30-60 days of overlap. Our goal is that you can operate independently after the transition. We’ve done this several times, and we consider it a success when a client outgrows us.

Managed vs. Building In-House

The honest answer: building in-house is better long-term if you can do it. An internal security team that understands your business deeply and is available full-time will always have advantages over an external team.

The question is whether you can actually do it right now.

Hiring a senior security engineer takes 3-6 months. Getting them fully ramped takes another 3-6 months. You’re looking at roughly a year from “we need security” to “we have effective security.” During that year, you’re exposed.

A managed function gets you to “effective security” in about 4 weeks.

The cost comparison is also worth examining. A senior security engineer’s total compensation (salary, benefits, equity) is a significant investment. A security team of three (which is what you actually need for reasonable coverage) costs substantially more. A managed function engagement typically runs well below the cost of building that team in-house, and you get a team of specialists, not a single generalist.

The hybrid model is often the best path. Start with a managed function to get your program established. Hire your first internal security person after 6-12 months, once you know what the role actually needs to look like. Transition the managed function to a support role and eventually phase it out as your internal team grows.

What This Isn’t

We’re not a body shop. We don’t send you a resume and a contractor who sits at your desk.

We’re not an MSSP. We don’t just watch dashboards and send you alerts to deal with.

We’re not a consulting firm that writes a 200-page report and disappears. We do the work. We implement the recommendations. We maintain the systems.

We’re the security team you’d build if you could hire four senior security people tomorrow. Except you can start next week instead of next year.

If this model sounds like it might fit your situation, let’s talk. The first step is always a conversation about where you are, where you need to be, and whether we’re the right fit. Not every company needs this, and we’ll tell you if you don’t.