Methodology
One operating model across every practice
Advisory, red teaming, secure builds, training, and GRC all run on the same nine-step operating model. It keeps engagements honest: evidence before opinions, priorities before activity, and validation before anyone declares victory.
Operating model
Discover → Model → Prioritize → Attack → Validate → Remediate → Govern → Train → Reassess
Nine steps, applied in proportion to the engagement. A two-week assessment and a year-long program run the same loop at different depths.
Step 1: Discover
Establish what actually exists: AI systems, data flows, identities, vendors, and the shadow deployments nobody put on a diagram. Every engagement starts from evidence, not assumptions.
Step 2: Model
Build the threat model and architecture picture — trust boundaries, attack paths, and dependencies. This is where AI risk becomes specific enough to act on.
Step 3: Prioritize
Rank exposure by business consequence, not novelty. Limited security capacity goes to the failures that would actually matter to operations, regulators, and customers.
Step 4: Attack
Authorized, scoped adversarial validation. Under written rules of engagement, we test whether the risks in the model are real in the system — controlled pressure, collected evidence.
Step 5: Validate
Confirm which controls held, which failed, and what detection saw. Control validation turns assumptions into a documented, defensible control map.
Step 6: Remediate
Convert findings into a sequenced remediation plan with owners and compensating controls. We stay engaged through fixes — remediation-focused is not a slogan.
Step 7: Govern
Institutionalize what was learned: policies, review gates, inventories, and evidence workflows aligned to NIST AI RMF and ISO/IEC 42001 — so improvement survives staff turnover.
Step 8: Train
Transfer capability to your team through targeted training built from your own environment and findings. The goal is a client who needs us for harder problems, not the same ones.
Step 9: Reassess
AI estates change weekly; assurance has a shelf life. Retesting and scheduled reassessment keep the risk picture current instead of commemorative.
Principles
The rules we do not bend
Threat-informed
Priorities come from how adversaries actually operate against systems like yours — not from a generic checklist's alphabetical order.
Evidence-based
Findings are demonstrated, not asserted. If we cannot show it, we do not report it.
Remediation-focused
An engagement that ends at the findings ended early. Roadmaps, fixes, and retesting are the point.
Executive-ready
Every technical result has a business translation that survives the boardroom without a glossary.
Authorized and scoped, always
Adversarial work happens under written authorization and agreed rules of engagement. No exceptions, no gray areas.
Practice 1 of 5
Advisory methodology
Advisory engagements move from evidence to decisions. We do not deliver observations and leave — every assessment ends in a plan someone can fund, sequence, and defend.
- Situation assessment: current posture, constraints, and the decisions leadership actually faces
- Evidence gathering: architecture review, stakeholder interviews, control and document review
- Risk framing: exposure translated into operational and board-level terms
- Option development: realistic paths with cost, effort, and risk trade-offs stated plainly
- Roadmap: sequenced recommendations with owners, dependencies, and checkpoints
- Executive alignment: briefings that get the plan decided, not just admired
- Follow-through: periodic reviews against the roadmap as conditions change
Practice 2 of 5
AI red team methodology
A sixteen-step process from written authorization through retesting — summarized here in five phases. Full detail on the AI Red Teaming page.
- Authorize and scope: written authorization, rules of engagement, safety constraints
- Understand: business context, asset inventory, architecture and identity mapping
- Model and plan: threat modeling and abuse case development agreed with your team
- Execute: controlled adversarial simulation with guardrail and detection validation
- Report and improve: risk-ranked findings, remediation planning, retesting, executive briefing
Practice 3 of 5
Secure build methodology
Security engineering is part of the build, not a review at the end. Every RedCell Build engagement carries controls, evaluation, and operational readiness through the whole lifecycle.
- Design: threat model, data classification, identity architecture, and guardrail plan before code
- Build: retrieval controls, tool boundaries, and logging implemented as features, not fixes
- Evaluate: quality and safety evaluation suites wired into CI from the first sprint
- Abuse test: adversarial testing drawn from our red team practice before launch
- Operationalize: runbooks, monitoring, cost controls, and incident procedures delivered with the system
- Handover: your engineers can run, extend, and defend what we built together
Practice 4 of 5
Training methodology
Training built for operators: current material, real lab environments, and outcomes you can observe in how the team works afterward.
- Scope: audience, skill baseline, and the behaviors the training must change
- Tailor: scenarios and labs adapted to your stack, sector, and threat model
- Deliver: practitioner-led instruction with hands-on labs, not narrated slides
- Assess: exercises that demonstrate capability; certificates of completion issued
- Reinforce: follow-up materials and optional office hours while skills consolidate
Practice 5 of 5
GRC methodology
Governance work that produces operating systems for risk reduction — controls that run, evidence that accumulates, and reporting that tells leadership the truth.
- Scope and map: obligations, frameworks, and one unified control map instead of five parallel ones
- Assess: evidence-based gap analysis against the frameworks that apply to you
- Design: controls and processes sized to your organization, written so people follow them
- Implement: remediation support with owners and realistic sequencing
- Operate: metrics, evidence automation, and audit support that make year two easier than year one
Explore RedCell services
The methodology is public because it should be. The value is in the execution — and the practitioners doing it.