When a Customer Asks for a "Security Certification": SOC 2, ISO 27001 and Security Questionnaires

SOC 2: an auditor's attestation report, not a certificate

SOC (System and Organization Controls) is a suite of assurance services that CPAs provide under professional standards set by the American Institute of CPAs (AICPA), giving users the information they need to assess the risks of outsourcing^[1]. SOC 2 covers service organizations (SaaS providers, data centers, managed services and the like). A CPA performs an examination under the AICPA attestation standards (AT-C 105 and AT-C 205) and gives an opinion on three things: whether management's description of the system is presented in accordance with the description criteria, whether the controls are suitably designed, and, in a Type 2, whether the controls operated effectively^[2]. The output is therefore a report containing the auditor's opinion and the system description (plus test results in a Type 2), not a certificate; the common phrase "SOC 2 certified" is, strictly speaking, a misnomer.

SOC 2 evaluates controls against the AICPA Trust Services Criteria, which fall into five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy^[2]. An examination can cover one or several categories, but whichever are chosen, it must address the "common criteria" shared by all five, and the criteria for Security are the common criteria^[2], which is why people say Security is always required. Whether to add the other categories is best decided by what you have promised customers in your contracts: if you guarantee uptime, consider Availability. The AICPA has published exposure drafts of proposed 2027 Trust Services Criteria and Description Criteria^[3]; a draft is not the current rule, so check the AICPA's announcements for the final text and when it applies.

Type 1 and Type 2

• Type 1: evaluates the system description and the suitability of control design as of a point in time^[2].
• Type 2: also evaluates whether controls operated effectively throughout a period of time, and the report includes a detailed description of the auditor's tests of controls and their results^[2].

Service organization management decides the length of the period^[2]. A company doing this for the first time can start with a Type 1 to confirm the design, then begin the Type 2 observation period. But ask the customer which one they want: a Type 1, which only covers design, may not satisfy a customer looking for evidence that controls keep working.

Who may read it, and the other SOC reports

Readers of a SOC 2 report need background such as the nature of the service, the limitations of internal control and complementary controls to understand it, so its use is restricted to "specified parties" with that knowledge: service organization personnel, existing customers, business partners, regulators, and prospective customers who gained that understanding during vendor due diligence^[2]. To publish something for the general public on your website, you need a separate SOC 3, a general-use report that omits the system description and the test details^[2]. SOC 1, by contrast, addresses controls relevant to customers' internal control over financial reporting and is mainly needed by the customers' financial statement auditors^[2]; a customer who asks specifically for SOC 1 is usually acting for its financial audit, not its security team.

Report quality varies

According to a May 2026 article in the AICPA's Journal of Accountancy, the AICPA's peer review reviewer alert asks reviewers to examine whether SOC 2 engagement timelines are reasonable and how firms use external SOC platforms, and to watch for engagements with identical reports, risk assessments, sample sizes and testing procedures that are not designed around the service organization's own risks^[4]. Whether you are hiring an auditor or reviewing a supplier's report, these are warning signs.

ISO 27001: certification of a management system

ISO/IEC 27001:2022 specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS), including the assessment and treatment of information security risks tailored to the organization; the requirements apply to all organizations regardless of type, size or nature, and excluding any requirement in Clauses 4 to 10 is not acceptable when claiming conformity^[5]. The certificate is issued by a third-party certification body after an audit. In Taiwan, certification bodies can apply to the Taiwan Accreditation Foundation (TAF) for accreditation; TAF only accredits and does not audit or certify organizations itself, and its accreditation scope for management system certification bodies includes ISO/IEC 27001 information security management system certification^[6]. So check not only the certificate but also whether the certification body that issued it is accredited, using the accreditation directory on the TAF website; TAF also warns that some unaccredited bodies misuse its accreditation mark on non-accredited reports^[6]. Implementation and the certification cycle are covered in the ISO 27001 guide.

A simple way to remember the difference:

• Issuer and output: SOC 2 is an attestation report issued by a CPA and restricted to specified parties^[2]; ISO 27001 is a certificate issued by a certification body.
• The question answered: a SOC 2 Type 2 answers "did these controls operate effectively over this period", with a detailed description of the tests of controls and their results^[2]; ISO 27001 answers "does this organization have an information security management system that meets the standard's requirements"^[5].
• Scope: both have one. For an ISO certificate, check which sites and services it covers; for SOC 2, check the boundaries of the system description and which categories were included.

Find out what the customer actually needs

Before committing budget, get clear answers to these:

1. Where the requirement is written: ask the customer for the written basis, such as a procurement policy, a contract clause or a vendor assessment form. If it says "SOC 2 Type 2, ISO 27001 or equivalent", you have options.
2. Who will read it: the customer's security or third-party risk team, its financial statement auditor (which usually means SOC 1)^[2], or a regulator? Different readers accept different evidence.
3. Which service is covered: an ISO certificate that covers only the head office may not cover the SaaS platform the customer will use.
4. If you have nothing yet: say so honestly and provide questionnaire answers, relevant policies and an implementation timeline; you can attach your cloud provider's reports as evidence for the infrastructure layer, but make clear they do not cover your application (see the next section).

Manufacturers asked about equipment or production-line security may be facing a different set of standards; see IEC 62443 and SEMI E187.

When the report period has ended: bridge letters

A SOC 2 report covers only its report period. The gap between the end of that period and the date the customer cares about is often filled with a bridge letter. Google Cloud, for example, describes bridge letters as attestations made by the service provider's management to bridge the gap from the end date of the SOC report to the customer's period end, summarizing material changes or issues in the internal control environment since then, and offers them for both SOC 1 and SOC 2^[7]. A bridge letter is management's own statement, not an auditor's opinion, so it suits only a short gap and cannot replace the next report.

Taiwan public-sector customers: what the Cyber Security Management Act requires of contractors

If the customer is a government agency or a specific non-government agency (see the Cyber Security Management Act overview for who qualifies), the requirement may come straight from the Cyber Security Management Act. Article 10 requires these agencies, when outsourcing the building or operation of information systems or the provision of information services, to select suitable contractors and require and supervise an effective security management mechanism; the procedures and environment the contractor uses for the outsourced work must have sound cyber security management measures in place or pass impartial third-party verification; and the two sides must sign a written contract setting out rights, obligations and liability for breach^[8]. The Act does not name a particular standard, so what evidence is accepted depends on the agency's tender documents and contract. TAF's accreditation scope also includes an ISO/IEC 27001 (CNS 27001) scheme with specific requirements for the Cyber Security Management Act^[6]; if you plan to answer a public-sector customer with a certificate, ask the agency first whether it requires that scheme.

Article 7 of the current Enforcement Rules (amended January 5, 2026) lists what the commissioning agency must pay attention to when selecting and supervising a contractor. The items that bear directly on suppliers include^[9]:

• Sufficient security staff with appropriate training, professional security certifications or similar experience; whether subcontracting is allowed, and the security measures subcontractors must have.
• For custom system development, the contractor must provide proof of security testing; if the system is one of the agency's core systems or the contract is worth NT$10 million or more, the agency must test it itself or commission a third party; any systems or resources not developed by the contractor must be labeled with their source and backed by proof of license.
• On violating cyber security laws or becoming aware of a security incident, the contractor must notify the agency immediately, along with the remedial measures taken; when the contract ends, the contractor's data held for the contract must be returned, handed over, deleted or destroyed.
• The agency will confirm the work periodically, or when it learns of an incident at the contractor that may affect the work, through audits or other appropriate means.

An ISO 27001 certificate attests to a management system; it is not the system security testing proof Article 7 asks for, so prepare the two separately.

Your cloud provider's SOC 2 is not your SOC 2

"We run on AWS, and AWS has SOC 2" does not answer the customer's question. The AWS Shared Responsibility Model splits the job in two: AWS is responsible for security "of" the cloud, meaning the hardware, software, networking and facilities that run its cloud services, and the customer is responsible for security "in" the cloud^[10]. With a service like EC2, the customer manages the guest operating system (including updates and security patches), the application software it installs and the configuration of the security group firewall; even with an abstracted service like S3, the customer remains responsible for its data (including encryption options) and permissions^[10]. AWS also recommends that customers review third-party audit attestation documents to determine which controls they inherit and which they still need to implement^[10]. Your cloud provider's reports vouch for its data centers and platform; your code, access rights, configuration and data handling still need your own controls and evidence.

When you get your own SOC 2 and your system runs in the cloud, the cloud provider is a "subservice organization" in your report. The system description can use the inclusive method, which includes the subservice organization's functions and controls, or the carve-out method, which excludes them^[2]. Under the carve-out method, the cloud provider's part sits outside the scope of your report, and readers have to obtain the cloud provider's own report to assess it.

Readers of a SOC 2 report also need to understand how two kinds of complementary controls work together with the service organization's controls: complementary user entity controls (CUECs), which the customers using the service must perform, and complementary subservice organization controls (CSOCs), which the carved-out subservice organization is expected to perform^[2]. This works in both directions. When you read your cloud provider's report, treat its CUECs as your to-do list and check each one. When you write your own report or answer a questionnaire, spell out what the customer must do (for example, managing its own user accounts and MFA settings), so responsibility is clear if something goes wrong.

Security questionnaires: build an answer library and an evidence folder

When you have no report or certificate yet, or the customer wants more detail, a security questionnaire arrives. Some customers use their own spreadsheets; others use industry-standard questionnaires such as Shared Assessments' Standardized Information Gathering (SIG) questionnaire, which has helped organizations standardize how they assess third-party risk for more than two decades^[11], and the Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ), which captures how a cloud service implements each control in the Cloud Controls Matrix (CCM). Submitting a CAIQ is the CSA STAR Level 1 self-assessment, and the results are published in the public STAR Registry^[12].

Answer library and evidence folder

• Write standard answers by topic (access control, encryption, backup, vulnerability management, incident response, personnel security, supplier management, business continuity) instead of starting from scratch on every questionnaire.
• Tag each answer with an owner, the date it was last confirmed, its scope (which product or site) and the matching evidence file, and map it to SIG, CAIQ or the SOC 2 and ISO 27001 controls you already have.
• Review answers immediately after a change of cloud provider, an architecture change or a security incident; have sales and security maintain the library together, and do not let sales edit technical answers on their own.
• In the evidence folder, keep security policies and procedures, the ISO certificate, the SOC 2 report and latest bridge letter, vulnerability scan or penetration test summaries with remediation records (see patch prioritization), backup restore and business continuity exercise records, training records, and a list of subservice organizations with their reports.
• A SOC 2 report is restricted to specified parties^[2]: have the customer sign a non-disclosure agreement before you share it, and record who received which version.

Never answer "yes" to a control you do not run

Questionnaire answers are not marketing copy; answer as if each one could end up in the contract, and remember that a CAIQ submitted to the STAR Registry is visible to anyone^[12]. If a control is only partly in place, answer "partially", describing the current state, compensating controls and a target date; if it truly does not apply, answer "not applicable" and say why. Before answering "yes", make sure you can produce the evidence; if you cannot, treat it as not done. Track any improvements promised in a questionnaire internally and report progress to the customer before the due date.

Action checklist

1. List every security request received in the past year (reports, certificates, questionnaires, contract clauses) with the customer, what was asked, the written basis and the deadline.
2. For each, confirm what the customer actually needs: SOC 2 Type 1 or Type 2, ISO 27001, SOC 1, or just a questionnaire, and whether "or equivalent" gives you room.
3. If you already have a report or certificate, check that its scope covers the services the customer uses and note the report period or certificate expiry; set up a process for issuing bridge letters.
4. Download your cloud provider's SOC 2 report, turn its CUECs into a to-do list and check each one.
5. If you decide to get a SOC 2, watch for unrealistically short timelines and boilerplate reports when choosing an auditor, and decide whether to use the inclusive or carve-out method for subservice organizations.
6. Build the questionnaire answer library and evidence folder with named owners and a review cycle; require an NDA before sharing a SOC 2 report.
7. If the customer is a government agency or specific non-government agency, check your documents and procedures against Article 10 of the Act and Article 7 of the Enforcement Rules. If you are unsure where the gaps are, start with a security health check.