A Customer Wants ISO 27001 or SOC 2 Before They’ll Sign — Where Do I Start?

By BCyber Security Team | CISSP, CISM Last updated: 7 October 2026

If a customer is asking for ISO 27001 or SOC 2 before they will sign, start by treating it as a trust and evidence problem, not a badge problem. In our work across BCyber’s platform inventory — 23 policies, 9 processes, 50 courses, 971 published articles, 563 knowledge hub entries, 11 clients, and 14 fact-find assessments — the fastest outcomes usually come from clarifying what the buyer actually needs, defining the service scope, and building a small but defensible control baseline with evidence.

This article is based on BCyber’s real-world compliance workflow patterns and our GRACE Portal view of control visibility, reporting, and compliance tracking. Where we reference statistics about BCyber assets, those figures are current at the time of publication and should be verified internally before reuse in procurement materials.

Potential bias note: BCyber provides cybersecurity and GRC advisory services, so we have a commercial interest in helping organisations prepare for assurance requests. We aim to present practical, framework-aligned guidance rather than pushing a single certification path.

What is the buyer really asking for?

ISO 27001 and SOC 2 are not the same thing

When buyers say “we need ISO 27001 or SOC 2,” they often use the terms loosely, but the deliverables are different.

• ISO/IEC 27001 is a management-system standard for building and operating an Information Security Management System (ISMS). The emphasis is on governance, continual improvement, internal audit, management review, risk treatment, and control ownership.
• SOC 2 is an attestation report against the AICPA Trust Services Criteria (TSC), commonly used in B2B SaaS and vendor due diligence. It focuses on whether controls are suitably designed, and — depending on the engagement — whether they operate effectively over a review period.

In practice, one customer may want a certificate, another may want a report, and another may only want a completed security questionnaire backed by evidence. If you assume the wrong outcome, you can spend weeks preparing the wrong artefacts.

A useful first question is: What decision does the customer need to make? If the answer is vendor onboarding, procurement approval, or contract signature, they are usually looking for evidence of control maturity — not a philosophical debate about frameworks.

Clarifying questions that save weeks of rework

Before you start writing policies or chasing audit quotes, ask:

1. Do you need a certificate, an audit report, or simply proof that core controls exist and operate?
2. Is this mandatory for every supplier, or only suppliers handling sensitive, regulated, or production data?
3. Is the requirement tied to pre-signature, pre-onboarding, or renewal?
4. Will a readiness pack satisfy interim due diligence?
5. Are you buying software, managed services, or processing high-risk data?

These questions matter because the buyer’s request may be driven by different control expectations depending on sector. For example:

• Financial services buyers often map expectations to APRA CPS 234 and resilience obligations, especially if the service supports regulated operations or privileged access to customer data.
• Healthcare buyers often care about patient confidentiality, access logging, and incident response because sensitive health information is harder to justify in a weak control environment.
• Government buyers frequently look for assurance against the Essential Eight and broader public-sector security expectations before systems are connected or data is exchanged.

If the answer differs across stakeholders, that is a signal the customer has not yet aligned internally. In that case, the best response is a concise evidence pack, not a sprawling compliance project.

The buyer is usually asking, “Can we trust your controls enough to take on this risk?” not “Have you collected the right badge?”

Scope is the hidden lever

Scope is where many teams lose time, because they try to secure everything instead of securing what is actually in review. You need to know which product, service, environment, and data set the customer is assessing. You also need to know which teams, cloud accounts, subsidiaries, and suppliers are in scope for that service.

A clear scope statement should define:

• In-scope product or service
• In-scope legal entity
• In-scope infrastructure and cloud accounts
• In-scope data types and data residency assumptions
• Out-of-scope systems and teams
• Third parties that materially support delivery

That scope boundary is essential whether you are aiming for ISO 27001 readiness or a SOC 2 report. It also reduces noise when mapping controls in Paradigm, BCyber’s AI Self-Learning GRC Platform, because control ownership and evidence can be tied to a defined service boundary instead of “the whole company.”

How do you set up the work so it does not sprawl?

Treat the request like a project with ownership

A customer assurance request can drift for weeks if it is handled as an ad hoc task. Assign:

• a project owner,
• an executive sponsor,
• and a small working group with clear responsibility.

At minimum, security, IT, legal, engineering, and operations should know what they own. If the service touches HR or finance systems, include those teams as needed.

A simple governance structure works best. For example:

• Executive sponsor: approves budget and risk acceptance
• Security lead: owns control mapping and evidence quality
• Engineering lead: owns technical implementation details
• Legal/procurement: handles customer wording and contract language
• Operations: confirms process execution

This approach aligns well with BCyber’s GRACE Portal view of single dashboard, cross-product analytics, executive reporting, compliance tracking, and real-time monitoring. In practice, that means one place to see what is complete, what is still missing, and which control gaps may block the deal.

Define what “good enough” means right now

Not every request requires immediate certification readiness. Sometimes the right near-term goal is to satisfy due diligence with evidence that shows control maturity. In other cases, the objective is to prepare for a formal audit later while still unblocking the deal now.

A practical way to think about this:

1. Now: show current, defensible evidence
2. Next quarter: close the highest-risk gaps
3. Later: decide whether to pursue formal certification or attestation

This is where risk quantification helps. BCyber’s Paradigm platform is designed to support GRC automation, policy automation, and compliance mapping, which is useful when leadership wants to understand which gaps matter most commercially and operationally. The goal is not to create more compliance theatre. The goal is to reduce uncertainty quickly.

Build a simple scope and inventory record

Once scope is agreed, create a short inventory of what already exists:

• current policies
• security tools
• risk assessments
• onboarding and offboarding processes
• incident response steps
• backup practices
• supplier review records
• training and awareness artefacts

BCyber’s platform inventory shows we maintain 23 policies, 9 processes, and 50 courses, which reflects a common reality: most organisations already have more security activity than they can easily evidence. The issue is usually not absence of controls; it is absence of proof.

What controls should you build first?

Start with a minimum viable security baseline

A buyer asking for ISO 27001 or SOC 2 is usually not expecting perfection. They want a defensible control set that demonstrates structured risk management.

The control domains that typically matter most are:

• governance
• risk assessment
• identity and access management
• incident response
• logging and monitoring
• backup and recovery
• supplier risk management
• security awareness

These domains map cleanly to ISO 27001 Annex A, the NIST Cybersecurity Framework, and the SOC 2 Trust Services Criteria. They also align well with the practical controls most procurement teams ask about.

The control areas that usually matter most

A practical baseline often includes:

• an approved information security policy and supporting policies
• a basic risk register with treatment decisions
• MFA for key systems and privileged access
• documented joiner, mover, leaver processes
• a defined incident response process and escalation path
• logging and monitoring for critical systems
• backup and restore procedures with test evidence
• vendor and supplier risk checks for critical third parties

These control areas are especially persuasive in sectors like:

• financial services, where privileged access, fraud exposure, and third-party concentration risk are closely scrutinised
• healthcare, where confidentiality, availability, and auditability matter because patient data misuse can become a clinical and legal issue
• government, where identity, logging, and resilience expectations are often benchmarked against the Essential Eight

If you need a practical learning path for staff, BCyber’s course library can support awareness and role-based upskilling. For example, compliance leads and control owners typically benefit from training aligned to risk management, incident response, and privacy fundamentals. That kind of training supports the control environment, not just the documentation layer.

Use Australian regulatory context where it matters

For Australian organisations, buyer expectations are often influenced by local regulatory pressure as much as by ISO or SOC 2 language.

Relevant examples include:

• APRA CPS 234 for information security expectations in regulated financial institutions
• the ACSC Essential Eight as a pragmatic benchmark for baseline hardening
• the Privacy Act 1988 and Notifiable Data Breaches scheme for handling personal information and breach response

A few practical sector scenarios:

• Financial services: A superannuation administrator may be asked to evidence vendor risk controls, MFA enforcement, and incident escalation aligned to APRA expectations before a fintech customer will proceed.
• Healthcare: A telehealth provider may need to show access controls, audit logs, and backup restore evidence before a hospital group approves integration.
• Government supply chain: A software vendor may be asked to prove administrative access restrictions, patching discipline, and data separation before a departmental procurement team signs off.

If the customer is asking for SOC 2 evidence, avoid turning the conversation into a framework lecture. Instead, show how your current controls support the assurance outcome they need.

Build evidence as you build controls

Controls are only persuasive when they are supported by evidence.

Good evidence is:

• versioned
• dated
• attributable
• current
• mapped to a control objective

Examples include:

• approved policies
• access review records
• tabletop exercise notes
• incident tickets
• backup restore test results
• vulnerability scan summaries
• supplier assessments
• change records for security-relevant systems

BCyber’s CyberTriage platform is relevant here because incident response evidence is often one of the first things procurement teams ask for. A 4-minute triage capability sounds impressive, but what matters to a buyer is whether triage, containment, and forensic investigation are supported by playbooks and records they can trust.

How do you map what you already have to the standard?

Control mapping turns a vague request into a working plan

Once you have a baseline, map your current controls to the relevant standard.

For ISO 27001, compare your environment to:

• the ISMS clauses
• risk treatment obligations
• Annex A controls

For SOC 2, compare your control set to:

• the Trust Services Criteria
• the system description
• control design and operational evidence requirements

For NIST, many teams use the NIST Cybersecurity Framework or related NIST guidance to structure technical controls and maturity discussions.

A simple matrix works well:

| Control | Owner | Evidence | Current status | Remediation priority | |---|---|---|---|---| | Access review | IT/security | quarterly review report | operating | medium | | Incident response | Security | IR plan + tabletop notes | operating | low | | Backup restore | IT | restore test evidence | partial | high |

This turns a vague “we need ISO/SOC 2” requirement into a visible workplan.

Evidence should answer the buyer’s real question

Ask what the buyer is trying to confirm:

• Can access be controlled?
• Are incidents detected and handled?
• Are vendors assessed?
• Can systems be recovered?
• Can the organisation explain what happens when things go wrong?

Evidence should answer those questions directly. If the buyer is reviewing a customer-facing SaaS platform, they often want to know how logical access, logging, backup, and separation of duties are handled. If they are reviewing a managed service, they may care more about support access, escalation, and incident reporting.

BCyber’s Profiler platform is relevant when human-factor risk, insider risk, or anomalous access patterns are in scope. Its behavioural analysis, insider threat detection, access pattern monitoring, risk scoring, and user activity analytics capabilities map well to controls that buyers increasingly expect to see in modern assurance reviews.

Common gaps that slow deal progress

Some gaps show up again and again:

• policies exist but are not approved or reviewed
• supplier risk is handled informally and never recorded
• logging is enabled but not documented
• access reviews happen but no evidence is retained
• risk assessments are old or generic
• incident response exists only as a draft document
• privacy and security obligations are mixed together without a clear boundary

These gaps matter because they weaken the story you are trying to tell. The buyer does not need every control on day one, but they do need to see that the missing pieces are known, prioritised, and being managed.

How do you package proof so procurement can use it?

Build an evidence library that is easy to trust

A strong evidence library is centralised, organised, and owned. Store documents in a secure repository with folders by control domain or framework mapping.

Your library should usually include:

• policies
• risk register
• access reviews
• security awareness records
• incident response artefacts
• backup test results
• vulnerability scan summaries
• supplier assessments
• system diagrams
• data flow diagrams

BCyber’s GRACE Portal can support this kind of structured view because it is designed for compliance tracking, executive reporting, and cross-product analytics. That makes it easier to present evidence in a way that procurement, legal, and security can all read without translation.

Customer-facing responses should be short and consistent

For most buyers, a tight security pack is more useful than a long document dump. Include:

• a short security overview
• architecture diagram
• data flow diagram
• policy summary
• incident response summary
• relevant certification or attestation status
• remediation roadmap if full assurance is not yet complete

If you are not yet certified, say so plainly. Then state what is currently operating and what the timeline is for the next assurance milestone. That honesty reduces the risk of overpromising.

If the customer uses frameworks like APRA CPS 234, Essential Eight, or ISO 27001, reference the controls you already have mapped rather than trying to restate the standard from memory. If they are in a regulated sector, point to the control objectives that are materially relevant to their review.

Avoid the evidence mistakes that damage credibility

A few mistakes can undo good work:

• outdated screenshots
• inconsistent policy versions
• raw logs without context
• unredacted internal details
• promising controls that cannot be demonstrated
• claiming “ISO compliant” without a certification body’s assessment

For SOC 2, be careful with terminology. If you do not yet have a report, do not imply you do. If you are pursuing readiness, say that. For ISO 27001, distinguish between “aligned to the standard” and “certified by an accredited body.”

That level of precision is one of the strongest trust signals you can send.

Should you pursue certification now or later?

Choose the path that matches the deal and the business

Not every customer request should trigger immediate certification work.

ISO 27001 makes sense when:

• you want a management-system-led security program
• enterprise buyers expect a globally recognised certification
• you can support continual improvement and surveillance audits

SOC 2 makes sense when:

• you sell software or services into markets where attestation reports are common
• your customers’ procurement teams expect a report they can review
• you need a repeatable external assurance story for B2B sales

If the customer only wants proof of specific controls, a well-prepared security pack may be enough for now.

A phased roadmap keeps the work under control

A sensible roadmap usually has four phases:

1. establish baseline controls and collect evidence
2. close the highest-risk gaps
3. run an internal readiness review
4. decide whether to pursue external certification or attestation

For teams that need broader visibility across business units, Paradigm can help connect policy automation, risk treatment, and compliance mapping. For executive reporting, GRACE Portal can show where the organisation is on the assurance journey. For resilience testing, Perfect Storm can be used to model compound scenarios and validate whether the control set can stand up to realistic threat combinations.

This is where assurance becomes a living system rather than a one-off project.

A simple decision guide

Use this logic when deciding what to do next:

1. If the customer only needs proof of controls, prepare the evidence pack and respond directly.
2. If the customer needs a formal report or certificate, assess whether you have enough maturity to start readiness work.
3. If the service is still too immature, build the baseline first and give the customer a realistic timeline.
4. If the deal depends on formal assurance, align the audit plan to the sales deadline.
5. If the requirement is flexible, choose the path that gives the best commercial and operational value.

That decision path keeps the conversation grounded and avoids turning every request into a certification emergency.

How do you turn one request into a repeatable advantage?

Make the response process reusable

Once you have answered the first customer well, capture the process so it can be reused:

• standard security overview deck
• core policy pack
• questionnaire response library
• control summary for sales and legal
• approval workflow for customer-facing answers

BCyber’s knowledge base scale — 971 published articles and 563 knowledge hub entries — reflects the value of reusable, governed answers. The point is not volume for its own sake. The point is consistency.

If you have 11 clients and 14 fact-find assessments across similar due diligence themes, the practical lesson is obvious: repeatability matters. The same assurance question will come back in a different format, from a different buyer, in a different sector.

Keep improving after the first deal is unblocked

The work should not stop when the customer signs. Review access regularly. Refresh risk assessments. Test backup and recovery. Revisit supplier risk. Update the evidence library after major changes.

If you do that consistently, the next assurance request becomes faster and less disruptive.

Sources and authoritative references

The guidance above is aligned to widely used security and assurance references, including:

• ISO/IEC 27001:2022
• AICPA SOC 2 Trust Services Criteria
• NIST Cybersecurity Framework
• NIST SP 800-53
• APRA CPS 234
• ACSC Essential Eight
• Australian Privacy Act 1988

BCyber also tracks customer assurance work in environments where organisations reference frameworks such as APRA CPS 234, Essential Eight, ISO 27001, SOC 2, and privacy obligations under Australian law.

BCyber recognition

BCyber leadership and team capability have also been recognised in industry awards, including:

• 2025 Finalist Cybersecurity Professional Of The Year — Karen Stephens, Co-Founder & CEO
• 2025 GRC Provider of the Year — Finalist
• 2025 AI Innovator - Cyber Security — Finalist

Key Takeaways

A customer asking for ISO 27001 or SOC 2 before they sign is usually asking whether they can trust your controls, not whether you can collect a certificate.

Start by:

• clarifying the exact deliverable
• defining the in-scope service and data
• building a defensible baseline of governance, access, incident response, logging, backup, and supplier controls
• collecting evidence that proves those controls are operating
• mapping your work to the relevant framework
• deciding whether certification or attestation is commercially necessary now

If you do that well, the request becomes more than a sales hurdle. It becomes the foundation of a stronger, more repeatable security practice.

Verification statement: BCyber platform statistics and product references in this article are based on internal platform data supplied for editorial use. Readers should verify any figures, certification claims, and control statements against current internal records before using them in customer-facing assurance materials.