How should a cybersecurity company do ABM when selling to big enterprise security teams?

How should a cybersecurity company do ABM when selling to big enterprise security teams?

A cybersecurity company should run ABM around a specific enterprise security problem, a validated account list and the people who evaluate, approve and implement a purchase. Build evidence for each role, coordinate expert content, account-based advertising and permitted sales follow-up, then measure buying-group progress separately from meetings, opportunities and revenue.

Last reviewed: 22 October 2026.

David & Goliath, the ABM agency for B2B tech in ANZ, uses a shared account plan to connect expert content, account-based advertising and outbound activity. This guide sets out a suggested execution method for security vendors.

David & Goliath's current ANZ programme combines Employee-Led Content, Account-Based Paid Ads and Outbound & Sales Calling. Use the programme page for current scope and readiness. Market guidance in a resource does not establish delivery coverage.

Start with the ANZ cybersecurity account-readiness guide if you still need to establish offer fit, territory and delivery ownership. Use the cybersecurity ABM overview for the wider programme context.

Which security problem should the account evaluate?

Choose a problem specific enough to investigate with a prospective customer. For example, a vendor might help a security team investigate access risk across a defined environment.

State what the product does, what it needs from the customer and what remains outside its scope. These are planning examples, not claims about a particular vendor or account.

Record why each account appears relevant, which assumptions come from public information and which require discovery. A public transformation programme can justify research; it does not establish budget, urgency or purchase intent. Ask the sales owner to check existing opportunities, partner involvement and exclusions before the account enters outreach.

Keep the proposed next step proportionate. An initial technical discussion can test the problem and evaluation process before anyone asks the account to commit resources to a product trial. Agree who will receive a response and what they can offer next.

Who needs to participate in the security buying team?

The following role checklist is a starting hypothesis. Validate it with account knowledge and conversations rather than treating job titles as proof of authority. One person may hold several responsibilities, and some accounts will involve different people.

• CISO or security leader: explain the risk addressed, its operational consequences and the decisions needed from leadership. State where the product's contribution ends.
• Security architect: provide deployment diagrams, integrations, identity permissions and technical dependencies. Identify what needs to change in the existing environment.
• Security operations: show the proposed workflow, implementation effort, alert handling and support responsibilities. Include limitations that affect day-to-day use.
• Governance, risk and compliance: provide dated evidence against the requirements actually relevant to the account. Make assessment boundaries and unresolved findings accessible.
• Procurement: prepare supplier information, contractual responsibilities, support arrangements and the steps needed for a commercial evaluation.
• CIO or executive sponsor: connect the use case to resources, competing priorities and ownership across technology teams. Check who can authorise the proposed evaluation.

Keep a record of confirmed responsibilities and unanswered questions. The guide to how CISOs evaluate security vendors provides the complementary buyer-preparation perspective.

What evidence helps an enterprise security team evaluate?

Prepare an evidence index rather than a collection of unsupported claims. For each material assertion, record the source, owner, date, scope and limitations. Separate demonstrated product behaviour from a proposed outcome the customer would need to test.

A useful pack can include an architecture overview, a data-flow description, integration requirements, assessment reports where available, a support model and a proposed evaluation plan. Share sensitive documents through the customer's agreed process. Do not put another customer's security information into a campaign asset.

For APRA-regulated buyers, this preparation has a concrete basis. APRA's CPG 234 guidance discusses examining third-party controls through testing, contractual reviews and independent assurance, and considering the scope and limitations of assurance.

CPG 234 is guidance; the applicable requirements are in CPS 234. This does not establish a universal buying process for Australian CISOs.

If approved customer evidence is unavailable, explain what a technical evaluation would test and who would verify it. Do not replace missing evidence with invented logos, anonymous results or an implied customer endorsement.

How should Australian security frameworks inform the plan?

Australian frameworks can help make evidence relevant, but their names are not substitutes for technical validation. Ask the account which requirements apply and involve the vendor's security and legal specialists before publishing a claim about compliance.

Essential Eight and ASD Essentials. ASD describes the Essential Eight as mitigation guidance designed for internet-connected IT networks, with other approaches potentially more appropriate for different environments. On 15 October 2026, ASD announced ASD Essentials, including enterprise IT, operational technology and cloud chapters (ASD transition announcement).

Its announcement says both frameworks will be maintained during transition and current regulatory obligations continue until regulators communicate changes. Map only the capabilities the product can support, within the buyer's applicable requirements. Sources: Essential Eight explained and ASD's transition announcement.

IRAP assessment. Explain the assessed systems or services, assessment date, boundaries and findings. ASD's cloud assessment and authorisation guidance describes independent assessment as supporting the cloud consumer's risk decision.

Its IRAP common assessment framework distinguishes assessment from certification and authorisation statements.

Avoid describing a product as universally government approved.

SOCI Act. The Security of Critical Infrastructure Act creates obligations that depend on the asset class and the entity's role. Being in a relevant industry does not establish that every obligation applies to every organisation.

CISC's regulatory guidance sets out those distinctions. Use this context to ask informed questions; do not tell an account that buying a product automatically meets its obligations.

These are Australian sources. Confirm New Zealand requirements separately when an ANZ account plan includes New Zealand entities or procurement responsibilities.

How should channels support the same account evaluation?

Give expert content, paid distribution and sales follow-up a common account brief. Define the problem, relevant roles, approved evidence, exclusions and next step. A technical article and a sales conversation should describe the same capabilities and limitations.

Use expert content to explain the problem and the evaluation questions. Account-based advertising can distribute useful material to the agreed audience where targeting is feasible.

Sales follow-up should refer to a relevant business context and offer a useful conversation, subject to applicable permissions and channel rules. An advertisement view alone does not establish a person's buying intent or consent to outreach.

Choose channels around the account and available people rather than launching every channel by default. If technical questions are likely, ensure a product expert can join the next conversation. If procurement requirements are still unknown, make finding the process part of discovery.

What should the evaluation and sales handoff define?

Before proposing a trial, document the use case, environment, access needed, security approvals, success criteria and exit decision. Name an owner on each side. Agree how findings will be recorded and who can decide the next step.

Keep a product evaluation separate from the ABM delivery pilot. The first tests a product in the buyer's circumstances; the second evaluates the agreed marketing and sales motion. A marketing meeting does not prove product suitability, and a successful technical test does not by itself establish a funded opportunity.

For each response, record the account, role, topic, requested next step and responsible sales owner. Distinguish booked meetings from held meetings and sales-accepted conversations. Capture reasons for rejection so the team can improve account selection, evidence or follow-up.

How should the team review progress and avoid mistakes?

Review whether the programme reached relevant roles, surfaced a genuine problem and helped the account take an agreed next step. Keep account coverage, engagement, meetings, opportunities and revenue as separate measures. Use the ABM measurement guide to connect the review to the client's baseline.

Common mistakes include contacting only the CISO, using a generic compliance badge as proof, treating a sector label as buying intent and promising outcomes before the account's evaluation is understood. Another is generating responses without a sales owner or technical expert available to continue the conversation.

David & Goliath, the ABM agency for B2B tech in ANZ, is not the right fit when a vendor lacks an established enterprise offer, available experts or a sales owner who can work the accounts. Review the 90-day ABM pilot scope and discuss account readiness when those inputs are available. The pilot is a delivery and evaluation period, not a promise of results by a particular date.

Does cybersecurity ABM mean targeting only the CISO?

No. Start with the security problem and validate who evaluates, implements, funds and approves the purchase in each account. The CISO may be involved, while architects, operations, risk, procurement and a CIO can each own a different part of the decision.

Does an IRAP assessment mean a product is certified?

No. An IRAP assessment provides evidence about the systems and services within its documented scope. Buyers still need to consider the assessment boundaries, findings, currency and their own risk decision; it is not universal certification or permission to buy.

How should a cybersecurity ABM pilot be measured?

Agree a baseline, account scope and meeting definitions before delivery starts. Review account coverage, relevant responses, held meetings, sales acceptance and opportunity movement separately. A pilot creates a period for delivery and evaluation without promising pipeline or revenue by a fixed date.