← back to blog

cloud phone SOC 2 readiness: what to ask your provider in 2026

cloud phone SOC 2 readiness comes up the moment a B2B customer asks for the SOC 2 report during a vendor security review. SOC 2 is not a regulation. it is an audit framework that demonstrates a service provider has implemented controls aligned to the AICPA Trust Services Criteria. enterprise customers ask for it because their own security review processes require it.

cloudf.one is not currently SOC 2 audited. that is the honest position, and it should be the first thing any team in a procurement cycle reads. our infrastructure controls map cleanly to SOC 2 criteria, and we maintain documentation and operational practices that align with the framework, but we have not gone through a Type I or Type II audit yet.

this guide covers what SOC 2 actually requires, what cloudf.one provides, what to ask any cloud phone vendor that claims SOC 2, and how to think about the gap if a SOC 2 report is mandatory for your procurement.

what SOC 2 actually requires

SOC 2 is a System and Organization Controls audit conducted by an independent CPA firm against the AICPA Trust Services Criteria. there are two types.

Type I attests that controls were designed appropriately at a point in time. Type II attests that those controls operated effectively over a period (usually 6 to 12 months).

the criteria fall into five categories:

• security (mandatory in every SOC 2)
• availability
• processing integrity
• confidentiality
• privacy

most cloud phone customers care primarily about security and availability, with confidentiality and privacy in scope when personal data is processed.

a SOC 2 report is the auditor’s written opinion. it is a long document covering the description of the system, the criteria, the controls in place, the testing the auditor did, and the results.

reference: AICPA’s SOC 2 overview explains the framework directly. the consumer-friendly summary site at soc2.com covers the basics.

what cloudf.one provides without a SOC 2 report

honest scope. we maintain operational practices that align with SOC 2 security and availability criteria. that is not the same as a SOC 2 attestation.

what is in place:

• network namespace isolation per phone, controlling traffic flow at the host level
• encryption at rest on the host filesystem for stored data
• TLS in transit for the control plane
• audit logs of administrative actions on the device fleet
• access controls limiting who can reach customer devices
• monitoring and alerting on infrastructure health
• documented incident response process
• physical security at the Singapore facility through the colocation provider
• breach notification commitments at the infrastructure layer
• documented vendor management for sub-processors

what is missing for a SOC 2 attestation:

• a third-party CPA audit
• a formal Type I or Type II report
• documented evidence trails covering the audit period
• the operational maturity to demonstrate effective control operation over time

these are not technical gaps. they are audit and documentation gaps. our roadmap includes pursuing Type I attestation in 2027.

what a SOC 2 report actually proves

worth being precise here. SOC 2 attestation does not mean a vendor is secure. it means an independent auditor reviewed the vendor’s controls against the Trust Services Criteria and issued an opinion at a point in time or over a period.

a SOC 2 report can have unqualified opinions, qualified opinions (the auditor identified exceptions), or adverse opinions (the controls did not meet the criteria). the actual usefulness of a SOC 2 report depends on reading it carefully.

things that SOC 2 reports typically include and that are worth checking:

• the system description (does it cover the service you are using?)
• the trust services criteria in scope (security at minimum, plus whatever else is relevant)
• the audit period and audit firm
• any exceptions noted by the auditor
• the controls tested and the results
• complementary user entity controls (what you, the customer, must implement)

a vendor with a SOC 2 Type II report is making a stronger claim than one with Type I. a vendor with no SOC 2 at all is making no claim either way; the underlying security may still be appropriate, just unaudited.

what to ask any cloud phone vendor about SOC 2

if SOC 2 is mandatory for your procurement, the questions that matter are concrete:

• do you have a current SOC 2 Type I or Type II report?
• if yes, can you share it under NDA?
• what is the audit period and which trust services criteria are in scope?
• which audit firm conducted the audit?
• were any exceptions or qualifications noted?
• what are the complementary user entity controls?
• if no SOC 2, what is your timeline?
• in the absence of SOC 2, what alternative attestations or assessments do you offer (ISO 27001, penetration test reports, security questionnaires)?

vendors that say “SOC 2 compliant” or “SOC 2 ready” in marketing without producing the actual report are making a marketing claim, not a security claim. press for the document.

the alternative paths if SOC 2 is mandatory

if your procurement requires SOC 2 today and a candidate vendor does not have one, your options are:

1. accept a security questionnaire response that documents controls without the third-party audit, paired with strong contractual commitments
2. require the vendor to commit to a SOC 2 audit timeline as part of the contract
3. choose a different vendor that already has the report
4. scope the workload so that the vendor’s infrastructure does not handle data that triggers your SOC 2 requirement

option 4 is often the cleanest answer. if your SG mobile ops workflow does not process the data category that drives your SOC 2 requirement, the SOC 2 question may not need to apply to the cloud phone vendor at all. that depends on your internal scoping rules.

practical controls that matter independently

independent of audit status, the controls that move the needle on cloud phone security are the same.

network isolation. our cloud phone IP leakage prevention writeup covers the network-namespace architecture that prevents cross-phone leakage.

audit logging. our cloud phone audit logs writeup covers the accountability layer that any compliance regime expects.

access control. who can reach the device, with what authentication, and how those sessions are logged. cloudf.one limits device access to the customer’s authenticated session through the control plane.

encryption. at rest on the host, in transit through TLS where the application supports it.

these controls are technical realities. SOC 2 attestation is documentation that an auditor verified them. both matter, in different ways, to a security review.

the simple decision

if SOC 2 is mandatory for your procurement and you cannot accept a vendor without an attested report today, cloudf.one is not the right fit yet. our roadmap includes Type I attestation in 2027.

if SOC 2 is preferred but not mandatory, or if your scoping rules allow vendors with strong infrastructure controls and an audit timeline, cloudf.one is usable. we are happy to share our security questionnaire response and discuss contractual commitments around our audit roadmap.

if you are evaluating providers that claim SOC 2, ask for the report under NDA. read the system description, the criteria, and the exceptions. a SOC 2 report is only as useful as what it actually says.

try it within scope

if you want to evaluate cloudf.one within a SOC 2-aware procurement, the free 1-hour trial gives you a real Singapore phone with no card. use it for technical evaluation while the procurement conversation runs in parallel.

start the free trial

frequently asked questions

is cloudf.one SOC 2 certified?

not yet. we maintain operational practices aligned with SOC 2 security and availability criteria, but we have not gone through a Type I or Type II audit. our roadmap includes Type I attestation in 2027.

can I still procure cloudf.one if my company requires SOC 2?

depends on your scoping rules. if SOC 2 is mandatory for any vendor processing your data, no. if it can be replaced with a security questionnaire and audit timeline commitment, yes.

what is the difference between Type I and Type II?

Type I attests that controls were designed appropriately at a point in time. Type II attests that those controls operated effectively over a period. Type II is the stronger claim because it covers ongoing operation.

what about ISO 27001?

different framework, similar idea. ISO 27001 is an information security management system standard. some procurement processes accept either ISO 27001 or SOC 2. cloudf.one is also pursuing ISO 27001 as part of the same roadmap.

what if a vendor says “SOC 2 ready”?

ask what that means concretely. it usually means the vendor believes their controls would pass an audit but have not been audited. that is not the same as a SOC 2 report. press for the report.