Security
Consulting
Strategy, architecture, AppSec programs and compliance readiness, from a practice that spends the rest of its time breaking the things it advises on.
The other engagements produce findings. This one produces decisions: what to build, what order to build it in, and what not to buy.
What you are buying
Fixed-scope advisory producing one specific artefact: a roadmap, an architecture review, a program design, a readiness assessment. Deliverables are named before the work starts.
The advice is worth taking because it comes from the practice that does the testing. A recommendation to change an identity model comes from having escalated through one. A recommendation to skip a tool comes from knowing what that class of tool misses. The published research is on the research lab.
The scope is what is listed below. Incident response retainers, digital forensics and crisis facilitation are not part of it. If you are in an active incident, engage a specialist IR firm first. We can help afterwards with what changes as a result.
Reasonable questions to bring
- → What does adequate security look like at our stage
- → Is this cloud architecture defensible
- → How do we get engineers to own AppSec
- → Do we actually need this tool
- → Where does AI tooling actually help us, and where does it just make noise
- → What has to be true before the audit
- → Which of these fifteen things should be first
Not offered
- → Incident response retainers
- → Digital forensics and breach investigation
- → Crisis communications and tabletop facilitation
- → Managed security operations
- → Tool resale or vendor referral arrangements
Six pieces of work
Durations assume a single system or a single framework. Larger estates extend them, and that gets said during scoping rather than during delivery.
01 · Offering
Security strategy and roadmap
Where the program is now, where it needs to be for the stage the business is at, and the ordered set of moves between the two. The output is a sequence with reasoning attached, not a maturity score.
Deliverables
- Current-state assessment against a defined target state
- Gap list ranked by exploitability and business exposure
- Phased roadmap with dependencies made explicit
- Budget and effort estimate per phase
- What to do in the first month, and what to defer
- Board-facing summary of the argument
Typical duration
3-6 weeks
02 · Offering
Cloud security architecture review
AWS or Azure environment reviewed as a design, not a checklist. Identity model, network boundaries, data handling, and logging coverage, with attention to which weaknesses actually compose into a path.
Deliverables
- Identity and role-escalation path analysis
- Network segmentation and trust boundary review
- Encryption, key handling, and secret storage review
- Logging and audit coverage assessment
- Infrastructure-as-code remediation your team can apply directly
- Ordered remediation plan
Typical duration
2-6 weeks
03 · Offering
Application security program design
Building the practice that means fewer findings next time. Security requirements engineers can act on, testing wired into the pipeline at points where it does not block delivery, and threat modelling that fits into how the team already works.
Deliverables
- Secure development lifecycle appropriate to your team size
- Security requirements and acceptance criteria
- SAST, DAST, and SCA integration with tuned thresholds
- Threat modelling method and worked example on your system
- Developer guidance grounded in findings from your own code
- Security champion structure and remit
Typical duration
6-10 weeks
04 · Offering
Compliance readiness
Getting to audit-ready for SOC 2, ISO 27001, PCI DSS, or HIPAA without building a control set that exists only to be audited. Where a control is genuinely required for your stage, we show why; where it is not, we say so.
Deliverables
- Gap analysis against the specific framework and scope
- Control implementation guidance, prioritised
- Policy and procedure documentation
- Evidence collection structure and templates
- Pre-audit readiness review
- Support answering auditor questions
Typical duration
6-12 weeks
05 · Offering
Security posture assessment
An independent read on where a program actually stands, across people, process, and technology. Commissioned by leadership wanting an outside opinion, or by an investor or acquirer wanting one that is not the internal team's.
Deliverables
- Assessment across identity, application, cloud, and operations
- Risk ranking with the reasoning shown
- What is materially wrong versus what is merely absent
- Recommendations sequenced by dependency
- Executive summary written for a non-technical reader
Typical duration
2-4 weeks
06 · Offering
Advisory retainer
Ongoing access for organizations that need senior security judgement periodically rather than continuously: design review before a decision is locked, vendor and tooling questions, and support preparing what leadership or the board is asking for.
Deliverables
- Scheduled review sessions at an agreed cadence
- Architecture and design review ahead of commitment
- Vendor and tooling evaluation
- Leadership and board reporting support
- Response to inbound customer security questionnaires
Typical duration
3-12 month terms
Buying against a deadline rather than a topic?
Consulting combined with hands-on testing, sequenced against a specific event, is packaged under Solutions. That covers acquisitions, cloud migrations, and release cadences that make annual testing stale.
How it runs
Drafts early, disagreement expected, scope fixed. Same shape across every offering above.
01
Discovery
What you are trying to accomplish, what is blocking it, and which constraints are real. Sometimes the useful outcome is that consulting is the wrong purchase and you need testing, or nothing at all yet.
Output: A clear read on whether this is worth scoping.
02
Scope and proposal
Named deliverables, defined boundaries, fixed scope. Not a time-and-materials arrangement that discovers its own shape as it goes.
Output: Statement of work with deliverables, timeline and fixed scope.
03
Gather context
Documentation review, stakeholder conversations, and read access to the systems in question. Structured to take as little of your team's time as the work allows.
Output: The context and access needed to produce the deliverable.
04
Analyse in the open
Assessment, architecture review, policy development, roadmap construction. Drafts are shared as they form, so a wrong assumption is corrected in week one instead of week five. You push back. A recommendation that does not survive your constraints is not a recommendation.
Output: Working drafts, then a deliverable revised against your feedback.
05
Deliver and stay reachable
Final materials, presented to whoever has to act on them. Board audiences get the argument in their terms with the technical basis intact. A defined window after delivery covers the questions that only appear once implementation starts.
Output: Final deliverable, walkthrough session, and a support window.
What lands on your desk
The artefact changes with the offering. These four properties do not.
Recommendations with reasoning attached
Every recommendation carries the risk it addresses, the reasoning behind the ordering, and the concrete next action. A recommendation you cannot argue for internally is not usable.
Ordering, not a list
The hard part of a gap analysis is the sequence, not the gaps. Deliverables state what comes first, what it depends on, and what can wait a year.
A direct answer on tooling
If a control is unnecessary at your stage, that is what the deliverable says. No resale margin or referral fee shapes the advice.
Written for the reader who must act
Engineering deliverables contain configuration and code. Board deliverables carry the argument without the technical basis being stripped out.
What we need to quote
The last item is the one most often left out and the one that most changes the shape of the deliverable.
- →The decision or deadline driving this: audit, board ask, customer requirement, migration, funding round.
- →What exists today: architecture documentation, prior assessments, current tooling.
- →Who owns security now, whether or not that is their job title.
- →Constraints that are genuinely fixed: budget, headcount, platform, regulatory scope.
- →Whether a framework is in play, and which scope of it applies.
- →What has already been tried and did not work.
- →Who has to be convinced by the output.
When to buy something else
Consulting fits
- → You need a direction, not a findings list
- → A framework deadline exists and nobody owns the plan
- → An architecture decision is about to be locked in
- → You have findings from testing and no plan for the class of problem behind them
- → You want an outside read that is not the internal team's
Start elsewhere if
- → You want to know what is exploitable: Penetration Testing
- → You are in an active incident and need an IR firm today
- → You need someone to operate controls day to day
- → You want a certificate rather than a defensible position
Common questions about security consulting
Still have questions about security consulting? Book a discovery call
How to start
Describe what you are trying to accomplish, what is blocking it, and the deadline. If consulting is not what you need, the first call will end with that instead of a proposal.
Direct: hello@principlebreach.com
Sequence
- Discovery call: is consulting the right purchase
- Statement of work with named deliverables
- Mutual NDA
- Information gathering
- Drafts shared as they form
- Delivery, walkthrough, implementation support window