This document describes the current procedural implementations and plans for CentML to fully adopt SOC 2 (System and Organization Controls 2). As CentML continues to pioneer in accelerating and optimizing machine learning workloads, adopting SOC 2 Type 1 and Type 2 controls is pivotal to reinforcing trust and security in our operations and services. SOC 2 compliance underscores our unwavering commitment to safeguarding customer data through stringent security practices and aligns with our vision to set industry benchmarks in AI/ML reliability and privacy. 

By embedding these controls into the very fabric of our organization, CentML is poised to enhance its business resilience, foster stronger relationships with stakeholders, and unlock new avenues of growth. This strategic move showcases our dedication to operational excellence and positions CentML as a trusted partner in the increasingly security-conscious landscape of enterprise AI/ML solutions, catalyzing our journey towards becoming the gold standard in secure machine learning platform services.

What is SOC 2

The SOC 2 (System and Organization Controls 2) is an assessment delivered by an AICPA-certified auditor (not within CentML’s organization). The assessment culminates in a report provided as deliverables. The assessment procedure and the report’s contents are governed by the American Institute of Certified Public Accountants (AICPA) SOC reporting framework. This basically means that whoever is delivering the SOC 2 assessment and resulting report is accredited with the AICPA and has experience going through the audit process.

SOC 2 reports evaluate an organization’s information systems in terms of robustness in security, availability, processing integrity, confidentiality, and privacy. Unlike SOC 1 reports, which focus on controls over financial reporting, SOC 2 reports address controls that directly relate to the system’s data, so this is more of a cybersecurity-focused assessment and report.

From the viewpoint of the 3rd party such a customer, an organization that achieved SOC 2 Type 1 and/or Type 2 compliance demonstrates its maturity and implementation of cybersecurity policies, procedures and controls to protect customer data. From the viewpoint of the auditor, an organization under SOC 2 assessment wishes to demonstrate that it is prepared, from the technology perspective, to protect customer data but also that it established an adequate level of internal “bureaucracy” to ensure that customer data is not easily exposable and that the organization actually takes the protection of customer data seriously. Finally, from a customer’s viewpoint, an organization with SOC 2 credentials stands out as the “beacon of safety” in a turbulent sea of various SaaS offerings, which constantly expose themselves to customer data leaks.

SOC 2 Type 1:

A SOC 2 Type 1 report is a snapshot that examines the design of a service organization’s data privacy and security controls at a specific point in time. It answers the question: “Are the system’s security controls suitably designed to meet the relevant trust services criteria right now?” Type 1 reports are helpful for organization leaders to understand the robustness of their control environment, but they don’t necessarily assure that the controls are operating effectively, as no testing over a period is done.

This is the first step to ensure there are adequate controls and policies in place.

SOC 2 Type 2:

A SOC 2 Type 2 report, on the other hand, goes a step further by not only examining the design of controls but also testing their effectiveness over a specified period (usually 6 months). This type of report provides assurance that the controls are not only properly designed but also effectively operational over the review period. Because of its scope, a Type 2 report is generally more comprehensive and useful for external organizations, such as clients or auditors, looking for assurance about the security and availability of the service.

Basically, this is the final and most crucial assessment (and the one customers actually care about) that demonstrates that not only an organization has the necessary policies and procedures in place but also that it follows them regularly and in a controlled/repeatable manner.

Usually, Orgs start with SOC 2 Type 1 which ensures they have the building blocks in place and then proceed to Type 2 which ensures they are using the building blocks correctly and on a regular basis.

What is required for SOC 2

This section defines what needs to be done by CentML before engaging a SOC 2 Auditor.

SOC 2 requires that there are policies in place at CentML that define how data is to be protected and safeguarded. SOC 2 also requires that there are procedures in place at CentML to a) implement the policies b) periodically review and update the policies. Lastly, the required policies and resulting procedures often require certain technical measures to be in place to support such policies and procedures. For example, the CentML Secure Access Policy defined a procedure for any remote CentML employee network access with mandatory Multi-Factor Authentication. Naturally, such a procedure requires a technical measure of integrating MFA into any remote access.

To summarize, Policies mandate Procedures realized/defined through Technical Measures.

Policies are usually documents with version control.

Procedures are usually descriptive actions and prescribed ways of doing things described in the policies.

Technical measures are usually artifacts, software, configurations, or human actions that realize procedures or create “guard rails” for them.

List of CentML policies for SOC 2

This is a list of documents that Pavel Stoev (Acting CISO) is creating within CentML and then reviewing by the CentML leadership committee. A track record of reviews is essential for SOC 2 assessment.

1. Secure Development Policy – generally defines secure version control of CentML documents, access to CentML code, but also the use of automated and manual security code review (yes, there is software for this, such as Veracode)
   
2. Code of Conduct – defines CentML Do’s and Don’ts document. Needs to be read and acknowledged by every employee when joining CentML and thus should be part of the onboarding process.
   
3. Security Incident Response Plan – document that describes actions by CentML management and CISO if there is a data breach or code leak or ransomware attack or another security incident. Basically, how to lockdown, who to notify and how to restore and clean up after the event.
   
4. Data Retention and Disposal Policy – lengthy description of how to dispose of data when it is no longer needed for CentML use, for example, if the customer of CentML products did not renew the contract. Putting disk drives into microwaves is possible but not exhaustive in this case.
   
5. Configuration and Asset Management Policy—This policy describes how CentML assets, physical or software, are procured, configured, regularly reviewed, and disposed of to prevent supply chain attacks.
   
6. Data Classification Policy – necessary to identify which data within CentML is sensitive and which is not and to establish procedures so as the two do not mix in terms of storage or access.
   
7. Risk Assessment and Treatment Policy – a document that describes that various internal and external risks are regularly considered by CentML management, identified and responded to.
   
8. Vulnerability and Patch Management Policy – to keep software and hardware systems used by CentML up to date and free of vulnerabilities (so long as the original equipment/software manufacturer patched them).
   
9. Business Continuity and Disaster Recovery Plan: what to do to restore CentML business operations and recover from an outage (recover customer data) in the event of a disaster or unmitigated risk realization. Data backups, backup retention, and backup testing are in the spotlight here.
   
10. Acceptable Use Policy: Do’s and do n’ts for CentML employees and contractors regarding company devices and data.
    
11. Network Security Policy – security zones on CentML networks and who can traverse them.
    
12. Performance Review Policy – CentML HR procedures but relevant to ensure employees get to report any issues.
    
13. Vendor Management Policy—The most important part of this policy is to prevent CentML from making black/grey market acquisitions of hardware/software that are prone to supply chain attacks.
    
14. Information Security Policy – comprehensive document on how data is protected within CentML.
    
15. Change Management Policy – comprehensive document on how changes are designed, reviewed and implemented to ensure they do not change existing risk profiles or create new unmitigated risks to CentML.
    
16. Encryption and Key Management Policy: Encrypt data in transit and at rest, according to the data classification policy developed earlier.
    
17. Access Control and Termination Policy – how physical and digital access is managed and how users are prevented from unauthorized access.
    
18. Physical Security Policy – who can enter the CentML physical office, data center and other data-containing locations.
    

Internal Control Policy—This is usually a comprehensive cybersecurity master plan that incorporates all aspects of the documents created in the list above.