A red-team engagement differs from penetration testing in objective, scope, and time horizon. Penetration testing finds vulnerabilities against a defined scope. A red team operates against a stated goal — exfiltrate a specific asset, achieve a specific outcome, or test a specific incident-response capability — with the scope and methods shaped by what an actual attacker would do, not by what an in-scope vulnerability list permits.
Melina Security runs red-team engagements for connected-product, SaaS, and AI-powered organizations where the standard penetration-testing frame is no longer the right tool — typically because the program has matured past the point where new findings come from broader scope and now needs to come from deeper scenario execution.
“The deliverable from penetration testing is a vulnerability list. The deliverable from a red team is the answer to a specific business question: could an adversary achieve this specific outcome, and if so, what defensive gaps enabled it. Two completely different products with different uses.” — Gleb Z., CTO, Melina Security
What this service covers
Goal-based adversarial assessment
Red-team engagements start with a goal definition exercise. Common goals:
- Exfiltrate specific high-value data (customer records, source code, signing keys, design documents)
- Achieve administrative control of a specific production system
- Achieve persistence in a specific infrastructure boundary that survives normal incident-response
- Test specific detection-and-response capabilities (could the SOC identify and contain this scenario)
- Test specific business-impact scenarios (can a single compromised endpoint create operationally-material harm)
The goal definition shapes engagement scope, time horizon, and authorized methods.
MITRE ATT&CK and MITRE ATLAS framing
We frame engagement execution against the MITRE ATT&CK taxonomy (for traditional adversarial scenarios) and MITRE ATLAS (for adversarial-ML scenarios). The framing is not constraint — it’s documentation. Coverage against ATT&CK tactics and techniques is reported alongside the engagement narrative, which gives the defending team a structured view of what was tested and where the gaps in detection or prevention emerged.
Threat-actor emulation
For engagements that emulate specific threat actors — typically clients with intelligence about specific groups targeting their sector — we operate against documented threat-actor TTPs. Threat-intelligence sources (commercial CTI feeds, industry-ISAC reporting, MITRE ATT&CK Groups documentation) shape the engagement narrative and the tooling choices.
Purple-team coordination
Most red-team engagements we run are purple-team in execution: red-team operations are coordinated with the defending team’s awareness and instrumentation, not run blind. This trades some adversarial realism for materially better defensive insight — the engagement produces a paired narrative of “what we did” and “what the defending team saw,” which is the output that produces improvement.
For engagements where blind adversarial-emulation is the explicit ask, we run that frame — but it’s typically the second engagement after a purple-team baseline has established what the defending team can see at all.
LLM and AI-powered system red teaming
AI/ML system red teaming is a related but distinct engagement frame. Where the AI system is one component of a larger goal-based scenario, AI red-teaming is part of the red-team engagement; where the AI system is the assessment target itself, the engagement runs under the AI/ML Security service.
Physical and operational scope (where applicable)
For engagement scopes that include physical and social-engineering vectors — typically large enterprise engagements with explicit board-level authorization — those vectors are framed with explicit pre-engagement authorization documentation, executive sponsorship, and operational coordination with HR / facilities / legal counsel.
Methodology
Red-team engagements operate across a longer time horizon than penetration testing (typically 4-12 weeks), with phased execution: reconnaissance and target development, initial access, persistence, privilege escalation, lateral movement, goal achievement, and reporting. Each phase is reported in real-time to the engagement sponsor, with go/no-go decisions at phase boundaries.
The engagement follows our six-stage methodology at the structural level, with red-team-specific extensions for goal definition, threat-actor selection, and rules-of-engagement detail.
What this service does not include
- Compliance-required penetration testing — that frame is better served by Scoped Assessment under the relevant service line
- Continuous adversarial testing services — those exist in the market as a separate product category; our engagement frame is project-based with retainer continuation
- Vulnerability-management-as-a-service — operator-driven
Compliance and standards we work within
- MITRE ATT&CK Enterprise / Mobile / ICS framework
- MITRE ATLAS for adversarial-ML scenarios
- TIBER-EU (Threat Intelligence-based Ethical Red Teaming) framework where applicable
- CBEST (UK financial sector red-team framework) for financial-sector engagements
- China-market: Red-team engagements coordinated with MLPS classification requirements
Engagement model
Red-team engagements are typically Custom Engagement — the scope, time horizon, and authorized methods require per-engagement structuring. Continuous-engagement extension (annual red-team exercises across multiple business units, recurring purple-team coordination) is typically Retainer.
Frequently asked questions
How is red teaming different from penetration testing?
Penetration testing finds vulnerabilities in a defined scope. Red teaming achieves a stated goal using whatever methods the rules-of-engagement permit. The output of penetration testing is a vulnerability list. The output of red teaming is a narrative of how a real attacker would achieve a real outcome, with the defensive gaps that enabled each step. Different deliverables, different uses, different cost structures.
Will a red-team engagement disrupt our operations?
Engagement execution is coordinated with the client’s operational team to avoid disrupting business operations. Where the engagement scope includes scenarios that could disrupt operations (a denial-of-service exercise, a data-destruction simulation), those scenarios run in isolated test environments rather than against production. Disruption-risk scenarios in production happen only with explicit written authorization and rollback plans.
Do you provide retainer-based continuous red teaming?
Our engagement model is project-based with retainer continuation rather than continuous-testing-as-a-service. For organizations seeking a continuous-testing capability, we coordinate with the operator’s broader security operations to make engagement value reinforce rather than parallel existing capability.
Can you red-team our AI / LLM systems specifically?
Yes — through either this service frame (where the AI system is one component of a goal-based scenario) or through AI/ML Security (where the AI system is the assessment target itself). The two engagement frames are complementary and often run in combination for mature AI deployments.
Will the engagement be reported to our regulators?
That’s a client decision. Our deliverable is the engagement report and the technical findings — reporting to regulators, executive bodies, or external stakeholders is the client’s decision under their compliance and disclosure obligations.
Related
- AI/ML Security
- What is OWASP LLM Top 10?
- Industries — AI/ML companies
- Methodology
- Rules of Engagement