Services

Annual programs

A twelve-month security testing program, built around your estate, your priorities and your budget. The example below rotates penetration testing across the year, with adversary simulation and purple team as a second stream.

Discuss an engagement

Term: Twelve months, built to renew
Scope: Shaped around your estate
Planning: One session each quarter
Shape: Customised, not packaged

A year of testing, planned as one program

Every program is different. What follows is an example of how one can be structured, not a package to buy. The activities, the rotation, the depth of each assessment and the balance between the two streams are all agreed with you, against your environment, your priorities and your budget.

An annual program replaces a series of disconnected engagements with a single twelve-month plan. Testing rotates across infrastructure, applications, cloud and identity through the year, so coverage is deliberate rather than incidental, and each quarter builds on what the last one found.

The program is structured as two streams. The testing stream is a complete program in its own right and produces the evidence base for remediation, audit and board reporting. The adversary stream is optional, and tests whether the weaknesses found in the testing stream can actually be exploited, and whether your security operations would see it happen.

The program year runs from whenever it starts, not from a fixed calendar date. Four quarters, one planning session each, and a year-end view that shows what changed rather than four independent snapshots.

One year establishes a baseline. Security maturity is built over several. We recommend running the program across multiple years, because the work compounds: scoping gets sharper, the same consultants keep the knowledge of your environment, and the results become a trend you can act on rather than a result you file.

To sketch a year of testing before the first conversation, use the continuous testing program planner.

Objectives and outcomes

Cover the estate deliberately

Infrastructure, applications, cloud, identity and APIs are scheduled across the year, so coverage follows a plan rather than whichever request happened to be raised

Remove the per-test overhead

One planning session a quarter replaces individual scoping requests, approvals and procurement workflows for every engagement

Verify that fixes hold

Retesting is built into each quarter, so a remediated finding becomes evidence that the security program is working rather than a line in an old report

Show progress over time

Four quarters of results in one place give trend data for board reporting, audit evidence and year-on-year comparison within the tested scope

Is an annual program the right fit?

An annual program suits organisations with a broad enough estate, or a fast enough rate of change, that a single yearly engagement cannot cover it meaningfully. Where the need is a defined application or a one-off technical question, a targeted assessment is the better answer and remains available on its own.

An annual program fits when

Have enough estate to cover that testing it once a year in a single engagement would be superficial.
Need a predictable testing calendar your internal teams and release schedules can plan around.
Are asked to evidence security posture and improvement to a board, an auditor or a regulator.
Ship changes through the year and want new releases validated rather than left until the next annual assessment.

Two streams

An example of what each stream can cover. The testing stream stands on its own; the adversary stream builds on what it finds, and can be added at any quarterly planning session. Which of these activities apply, and how deep each one goes, is agreed during scoping.

01
Testing stream
- Internal infrastructure, Active Directory and identity, tested together because the attack paths between them are coupled. Delivered onsite where the environment calls for it, and scoped separately for each distinct organisation or forest
- External infrastructure: asset discovery, service analysis, exposed management and remote access surfaces, mail gateway and email authentication configuration, and the forgotten services nobody has an owner for
- Cloud configuration review across the accounts in scope, covering identity and access policies, privilege escalation paths, cross-account trust, data exposure, network controls, secrets handling and logging coverage
- Web applications, batched across quarters and prioritised by business criticality, change frequency and known risk. Effort is matched to complexity rather than applied evenly
- APIs and web services as a dedicated assessment, covering object and function level authorisation, token handling, rate limiting, versioning gaps and undocumented endpoints
- Release validation each month for applications that ship changes after their first assessment, and retesting each quarter to verify that fixes are complete
02
Adversary stream
- Quarterly campaigns alternating between perimeter assessment and assumed breach, each time-boxed and objective-driven rather than full-scope red team operations
- Perimeter campaigns test realistic attack chains against external services and whether external threat activity is detected. Assumed breach campaigns start from a simulated internal foothold and test lateral movement, privilege escalation, persistence, data access and evasion
- A social engineering thread that runs all year rather than as isolated campaigns. Phishing infrastructure is established early and maintained, so sending reputation builds the way a real adversary's would, and pretexts evolve across the year instead of testing a single snapshot
- Purple team sessions where operators replay techniques alongside your security team, who validate detection coverage and identify gaps in real time. Cooperative by design, not adversarial
- A TTP detection register that records every technique tested, how it was executed, whether it was detected, and what changed after remediation

How a year can rotate

An example year, not a fixed schedule. The sequencing below is not arbitrary: testing stream findings inform the adversary campaigns that follow, and those campaigns validate whether the remediation held. Purple team sessions close the loop by building detection for the techniques both streams surfaced. A program with different priorities rotates differently and may not need every activity shown here, and the exact schedule for each quarter is confirmed at its planning session.

01
First quarter
- Testing stream: internal infrastructure, Active Directory and identity, plus the first batch of priority applications. Front-loading the applications that matter most gives the longest remediation runway before year end
- Adversary stream: a perimeter campaign establishes the adversary baseline from outside, and the social engineering infrastructure for the year is set up
02
Second quarter
- Testing stream: external infrastructure and the second application batch
- Adversary stream: the first assumed breach campaign, using the internal findings from the first quarter to target where weaknesses were identified and test whether the remediation holds under pressure. The first purple team session establishes a detection baseline
03
Third quarter
- Testing stream: cloud configuration review, API surfaces and the third application batch
- Adversary stream: a second perimeter campaign that validates whether the external weaknesses found in the previous quarter were effectively remediated
04
Fourth quarter
- Testing stream: deliberately lighter on new testing, leaving room for remaining applications, deeper dives into areas of concern and overflow from earlier quarters
- Adversary stream: a second assumed breach campaign covering persistence, evasion and exfiltration paths, and a final purple team session drawing on the full year of campaign data

How the program runs

The mechanics that keep a twelve-month engagement moving without a scoping conversation every time something changes.

01
Quarterly planning
- At the start of each quarter, both teams agree what will be tested, which consultants are allocated and when the testing windows fall
- One session replaces the scoping requests, approvals and procurement workflow that each individual engagement would otherwise carry
- Between sessions, a nominated customer success contact handles ad-hoc requests, urgent testing, release validation and scheduling changes
02
Reserved capacity
- A share of the program's capacity is held back rather than allocated up front, so unplanned work does not require a contract amendment or a new procurement cycle
- It covers urgent release validation, response to a newly published critical vulnerability, extended retesting, deeper dives into areas of concern, and campaign extensions where a promising attack path deserves more time
- Draws are agreed by both parties and documented with their purpose and deliverable. Capacity unused at year end carries into the next year's planning rather than expiring quietly
03
Testing windows
- Windows are booked wider than the testing effort itself, with buffer either side for access verification, credential provisioning and scope confirmation before, and report writing, quality assurance and debrief after
- Booking a window to the exact number of operator days is what compresses timelines later. Recommended windows are proposed at the planning session so internal availability can be arranged around confirmed dates
- Testing can be suspended at any time with immediate effect, and resumes by agreement
04
Scope, agreed and refined
- Scope assumptions are reviewed and confirmed before the program is agreed, then validated in detail during the first quarter
- Where the environment turns out to differ materially from the assumptions, adjusted options are presented within the agreed allocation before any work proceeds
- A second year benefits from a full year of familiarity with the environment, and is scoped far more precisely as a result

Deliverables and cadence

Every quarter produces a plan, reports and verified retests, with the Client Portal holding the record across the whole year:

Quarterly plan

Agreed scope, allocation and testing windows for the quarter ahead

Engagement reports

Per activity, for technical and executive audiences

Retest verification

Evidence that findings were remediated, each quarter

Client Portal

Posture across all activity, remediation progress and every report in one place

HackTrack

Real-time collaboration between operators and your security team during purple team

TTP detection register

Every technique tested, its detection result and remediation status

Campaign debriefs

Technical and executive, following each adversary campaign

Year-end reporting

Four quarters of results as trend data for board and audit use

Why we recommend a multi-year program

A single year tells you where you stand. It cannot tell you whether you are improving, and improvement is the thing a board, an auditor or a regulator actually asks about. We recommend committing to more than one year, and we structure the program so that each one is worth more than the last.

01
Year one: establish the baseline
- A complete picture across every layer of the attack surface, and four quarters of evidence showing which findings were remediated and verified
- Scope stops being an assumption. The first quarter validates it in practice, and the team learns how the environment is actually run rather than how it is documented
- The detection register opens, and the first baseline of what your security team sees is established
02
Year two: test what changed
- Scoping is far more precise, because a year of operational familiarity replaces guesswork. Effort shifts from discovery towards depth
- Results are read against last year's, so reporting shows direction rather than a list. Regression testing confirms that the detections built in year one still fire
- Campaigns push into the areas that held up under pressure the first time, because the easy ground has already been covered
03
Year three and beyond: raise the ceiling
- With the obvious weaknesses closed, testing moves to the attack paths that only appear under sustained pressure and patient tradecraft
- Detection maturity is measured as a multi-year trend rather than a result per engagement, which is the evidence a board can act on
- This is usually the point where continuous operations through CAOS (Continuous Adversary Operations Service) replace quarterly campaigns, and the relationship moves from testing your defences to pressure-testing them without pause

Why SilentGrid

A program is supported by a named customer success contact responsible for scheduling, communication and escalation, so testing windows are met without the coordination falling to your security team. Consultants are allocated per activity by specialisation, and high retention means the people who learned your environment in the first quarter are still the ones testing it in the fourth, and the year after.

SilentGrid holds CREST ANZ accreditation and tests to OWASP for web and API, PTES for infrastructure, CIS Benchmarks for cloud configuration and MITRE ATT&CK for technique mapping. Automated tooling is used for reconnaissance and coverage validation only. Exploitation, business logic testing and adversary simulation are manual, operator-led work.

CREST ANZApproved company

Individual credentials across our team include

OSEE
OSCE3
OSED
OSEP
OSWE
GXPN
CRTO
CRTE
CRTP
OSCP

Meet the team

Common questions

Is this exactly what our program would look like?

No. The streams and the rotation on this page are an example of how a program can be structured, drawn from a real one. Every program is built around the organisation it is for: which activities are included, how deep each one goes, how the year is sequenced and how much of it runs are all agreed during scoping, against your environment, your priorities and your budget. A smaller estate or a tighter budget produces a smaller program, not a worse one.

Should we commit to more than one year?

We recommend it. A single year establishes a baseline; it cannot show whether security is improving, which is what a board or a regulator asks about. From year two the scoping is far more precise because the environment is known, effort shifts from discovery to depth, regression testing confirms that earlier detections still fire, and the results read as a trend. Programs are agreed a year at a time, so the commitment is renewed on evidence rather than locked in up front.

Can we take the testing stream on its own?

Yes. The testing stream is designed as a complete, standalone program and delivers a full year of structured penetration testing without the adversary stream. The adversary stream can be added at program start or at any quarterly planning session, and its rotation adjusts to begin from whichever quarter it joins.

How is the scope agreed?

Scope assumptions are reviewed and confirmed before the program is signed, then validated in detail during the first quarter. If the environment materially exceeds the assumptions, adjusted options are presented within the agreed allocation before work proceeds, and a scope amendment is proposed where the variance is significant.

What happens when something urgent comes up mid-quarter?

Reserved capacity exists for exactly that: an unplanned release that needs validating, a newly published critical vulnerability affecting your infrastructure, or a deeper dive into something testing surfaced. Requests go through your customer success contact rather than a new procurement cycle.

Does the program have to align to our financial year?

No. The program runs for twelve months from whenever it starts, divided into four quarters of its own. If the start date happens to align with your financial year, reporting maps naturally to your budgeting and board cycles. If it does not, year-end reporting can be adjusted to coincide with the financial year close.

How often does purple team run?

Either two longer sessions a year or four shorter ones. Fewer, longer sessions suit teams that need time between them to implement findings. A quarterly cadence suits teams with dedicated detection engineering capability who can action gaps quickly. The cadence can be changed at any quarterly review, and the total annual allocation stays the same either way.

What if our security team cannot join a purple team session?

The exercise still runs and the findings are still delivered, but detection validation is limited to what can be assessed without active participation. Purple team is collaborative by design, and the value comes from your team observing technique execution as it happens.

How is this different from buying assessments one at a time?

Individual assessments each carry their own scoping, approval and scheduling overhead, and produce results that are hard to compare. A program plans coverage across the year, builds retesting in, and produces four quarters of comparable data. It also means the same consultants keep learning your environment rather than starting from scratch each time.

Where does CAOS fit?

CAOS replaces the quarterly adversary campaigns with persistent, continuous operations by a dedicated team. It can complement a program by taking over the adversary stream while the testing and purple team streams continue, or run as a standalone service. A year of program data is a natural foundation for it.

Planning next year's testing?

Get started with an annual program

Tell us what the estate looks like, what the year has to evidence and what the budget allows, and we will shape a program around it.

Nothing on this page is fixed. Scoping starts from your environment and the priorities behind the year, and the program is built from there: which activities run, how often, and in what order. The first quarter then validates that scope in detail, and each year is agreed on the evidence the last one produced.

Discuss an engagement Explore all services