SOC2

Cloud DevOps/Cloud Change Management Process.md

@@ -0,0 +1,82 @@
+# ITOM Cloud Service Delivery : Cloud Change Management Process
+
+Created by Yun Zhao, last modified on Jan 23, 2025 EST
+
+## Introduction
+
+This document describes how to manage changes in an Opentext Cloud environment. 
+
+## Change Type
+
+### Planned Change
+
+Change is defined as anything - hardware, software, system components, services or processes that is deliberately introduced into the production environment and which may affect a service level agreement (SLA) or otherwise affect the functioning of the environment or one of its components.
+
+  
+Changes may be required for many reasons, including, but not limited to:
+
+- User requests
+- Vendor recommended/required changes 
+- Changes in regulations
+- Hardware and/or software upgrades
+- Hardware or software failures
+- Changes or modifications to the infrastructure
+- Unforeseen events
+- Periodic Changes
+
+All changes falling under this definition should be governed by a change management policy, and implemented by a change management methodology and change management process.
+
+Planned Changes will be scheduled at least two (2) weeks in advance when Customer action is required, or at least four (4) days in advance otherwise. 
+
+### Emergency Changes
+
+Critical change to prevent service functionality or availability.
+
+Emergency Changes require approval of Cloud Delivery Manager, TO Manager or CS Manager.
+
+Emergency Change will be scheduled at least one (1) day in advance unless it is critical to resolve a major incident immediately.
+
+## Customer Notification
+
+Opentext Cloud Service will use a centralized notification system to deliver proactive communications about service changes, outages, and scheduled maintenance.  
+Details can be found on the relevant Service Health portal for your service which includes:
+
+- Current availability of the SMAX environment that their tenants are part of
+- Details of any upcoming planned maintenance
+- Outage reports for any incidents that have been identified by our support teams
+- Historical SLO data
+
+For example: [https://smax-health.saas.microfocus.com/](https://smax-health.saas.microfocus.com/)
+
+## Change Approval
+![[IMG-20260917124012726.png]]
+  
+
+## Change Record
+
+For any changes, need to submit change record in the [Essentials](https://essentials.saas.microfocus.com/itg/dashboard/app/portal/PageView.jsp) system.
+
+For details, please refer to document How to submit Change Record in Essentials System.
+
+## CAB Review
+
+### No CAB Required 
+
+Such change will not be discussed in the CAB meeting. List of changes that are mostly routine and were pre approved by an executive.  
+The likelihood of those changes to disrupt service is very slim and those changes are executed frequently.  
+e.g.:
+
+- Monthly Patch Upgrade
+- Routine EKS upgrade
+- etc.
+
+### CAB Required:
+
+All non exempt changes, mostly changes that will occur during maintenance window, and involves more than one executer.
+
+e.g.:
+
+- Product major version upgrade
+- AWS Infrastructure Change
+- Landing zone migration
+- etc.

Cloud DevOps/FedRAMP Basics Understanding Federal Cloud Security Standards.md

@@ -0,0 +1,229 @@
+---
+title: "FedRAMP Basics: Understanding Federal Cloud Security Standards"
+source: "https://drata.com/learn/fedramp/overview?vector_id=23842318473&vector_source=GOOGLE&vector_campaign=PMax_NAMER&utm_campaign=goog_all_all-pmax_AMS_NA_USCA_demo_requestdemo&utm_source=google&utm_medium=paidsearch&utm_term=&utm_content=&utm_campaignid=23842318473&utm_adgroup=&utm_creative=&utm_targetid=&gad_source=1&gad_campaignid=24079419334&gbraid=0AAAAABpLT4_7R2UdbvMfoq7wHaa-FMRKX&gclid=CjwKCAjw_KjVBhAHEiwAnC0N9P-0jFy0t9AajAAPm42Tpb4dPS-_5FoHbk-7EZ0Y8hWO5_jI7gHLoBoC3hYQAvD_BwE"
+author:
+  - "[[Drata]]"
+published: 2026-02-13
+created: 2026-09-17
+description: "What is FedRAMP? FedRAMP is a U.S. government program that standardizes security assessment and authorization for cloud services used by federal agencies."
+tags:
+  - "clippings"
+---
+What is FedRAMP? FedRAMP is a U.S. government program that standardizes security assessment and authorization for cloud services used by federal agencies.
+
+Federal agencies can't just sign up for any cloud service—they need FedRAMP authorization first. The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government-wide program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies.
+
+This guide covers how FedRAMP works, the authorization paths available, required security baselines, and how to navigate the certification process from initial assessment through ongoing compliance.
+
+## What Is the Federal Risk and Authorization Management Program
+
+The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government program that standardizes how cloud services get security clearance to work with federal agencies. Instead of each agency separately vetting every cloud tool they want to use, FedRAMP creates one security assessment that works across the entire government.
+
+Here's the core idea: get authorized once, use everywhere. A cloud provider goes through security evaluation one time, and that authorization becomes valid for any federal agency. Before FedRAMP launched in 2011, agencies were stuck doing redundant work—each one independently evaluating the same cloud services, often asking for the same documentation and running similar security tests.
+
+FedRAMP builds on security requirements from the National Institute of Standards and Technology (NIST) Special Publication 800-53FedRAMP builds on security requirements from the National Institute of Standards and Technology (NIST) Special Publication 800-53. Once a cloud service earns FedRAMP authorization, federal agencies can adopt it without starting from scratch on security reviews.
+
+## Why FedRAMP Compliance Matters for Cloud Providers and Agencies
+
+For cloud providers, FedRAMP opens access to federal contracts. Yet the value extends beyond government sales—commercial customers often view FedRAMP as proof that a provider takes security seriously.
+
+Federal agencies get pre-vetted cloud services without spending months on individual assessments. This accelerates technology adoption while maintaining security standards for government data.
+
+The benefits break down clearly:
+
+**For cloud providers:**
+
+- Access to federal contracts
+- Competitive edge in commercial markets
+- Faster government sales cycles
+- Fewer redundant security assessments
+
+**For federal agencies:**
+
+- Cloud services meeting consistent security standards
+- Faster procurement timelines
+- Lower evaluation costs
+- Standardized risk assessment
+
+## FedRAMP Impact Levels and Security Control Baselines Explained
+
+FedRAMP defines three security levels—Low, Moderate, and High—based on what happens if data gets compromised. The level you choose determines how many security controls you implement and how rigorous your assessment becomes.
+
+Impact level isn't about your company's internal operations. It's about the federal data your service will handle and what would happen if that data were exposed, altered, or made unavailable.
+
+### Low Baseline
+
+Low baseline covers publicly available information where unauthorized access causes minimal damage. Think data that's already public or meant for public release. This level requires 125 security controls and represents the entry point for FedRAMP.
+
+### Moderate Baseline
+
+Most FedRAMP authorizations fall under Moderate, which handles sensitive but unclassified information. A breach here could seriously harm agency operations, assets, or people. Moderate requires 325 security controls and represents the standard for federal cloud services processing operational data or personally identifiable information.
+
+### High Baseline
+
+High baseline protects highly sensitive data where unauthorized access could cause severe harm to national security, agency operations, or individuals. This includes classified information, law enforcement data, or critical infrastructure controls. High requires 421 security controls and involves the most intensive assessment.
+
+## FedRAMP Authorization Paths: JAB P-ATO vs Agency ATO
+
+Cloud providers can pursue FedRAMP through two main routes, each with distinct advantages depending on your business goals.
+
+### Joint Authorization Board Route
+
+The Joint Authorization Board (JAB) includes Chief Information Officers from the Department of Defense, Department of Homeland Security, and General Services Administration. When JAB grants a Provisional Authority to Operate (P-ATO), any federal agency can use your cloud service without additional authorization.
+
+JAB typically takes 12 to 18 months from initial assessment to authorization, but provides the widest market access. If you're building for multiple agencies, JAB authorization pays off through broader adoption.
+
+### Single Agency Route
+
+The agency-specific path lets you work directly with one federal agency to obtain an Authority to Operate (ATO) for that agency's use. This route often moves faster—sometimes 6 to 12 months—because you're working with a single decision-maker rather than a board.
+
+Your initial ATO only covers that specific agency, though. Other agencies can leverage your authorization, but they'll conduct their own review before granting their ATO.
+
+### Leveraging an Existing ATO
+
+Once you have initial FedRAMP authorization—whether P-ATO or agency ATO—other agencies can reuse your security documentation to speed up their decisions. Agencies review your existing package rather than starting fresh, which dramatically cuts time and cost for expanding to new government customers.
+
+## Step-by-Step FedRAMP Certification Process and Timeline
+
+The path to FedRAMP follows a structured process, though timelines vary based on your authorization route and system complexity.
+
+### 1\. Readiness Assessment
+
+Before engaging a formal assessor, you evaluate your current security against FedRAMP requirements. This self-assessment identifies gaps between your existing controls and FedRAMP baselines, letting you fix issues before the expensive formal assessment begins. Most organizations spend several months on remediation.
+
+### 2\. 3PAO Security Assessment
+
+A Third-Party Assessment Organization (3PAO)—an independent security assessor accredited by the American Association for Laboratory Accreditation—evaluates your security controls. The 3PAO tests whether your controls actually work as documented and meet FedRAMP requirements. This typically takes 2 to 4 months depending on system complexity.
+
+### 3\. Remediation and POA&M
+
+After assessment, you address identified vulnerabilities and create a Plan of Action and Milestones (POA&M) for issues you can't immediately resolve. The POA&M documents your remediation timeline and risk mitigation approach. Agencies or JAB review how you're managing ongoing risks as part of their authorization decision.
+
+### 4\. Authorization Decision
+
+For JAB authorization, the board reviews your complete security package and decides whether to grant P-ATO. For agency authorization, the agency's authorizing official reviews documentation and makes a risk-based decision to grant ATO. This review can take several months.
+
+### 5\. Marketplace Listing
+
+Once authorized, your service appears in the FedRAMP Marketplace—the official repository where federal agencies discover authorized cloud services. Your listing includes authorization level, date, sponsoring agency (for ATOs), and system description.
+
+## Continuous Monitoring and Annual FedRAMP ATO Renewals
+
+FedRAMP authorization isn't one-and-done—it requires ongoing compliance through continuous monitoringFedRAMP authorization isn't one-and-done—it requires ongoing compliance through continuous monitoring. Organizations often underestimate the operational work of maintaining authorization, leading to gaps that can jeopardize their status.
+
+### Monthly Reporting Requirements
+
+You submit monthly continuous monitoring deliverables to the FedRAMP Program Management Office (PMO), including vulnerability scan results, POA&M updates, and significant change documentation. Monthly reports demonstrate that your security remains consistent with your authorization and that you're actively managing risks.
+
+### Annual Penetration Test and Assessment
+
+Every year, your 3PAO conducts penetration testing and annual assessment to validate that security controls remain effective. The 3PAO performs active testing to identify new vulnerabilities and verify control implementation. Annual assessment ensures your authorization stays current as your system evolves.
+
+### Managing Significant Change Requests
+
+When you make substantial changes to your system—adding functionality, changing infrastructure, or modifying security controls—you submit a Significant Change Request to the PMO or your authorizing agency. This process ensures modifications don't introduce new risks or weaken security.
+
+## Navigating the FedRAMP Marketplace to Become a FedRAMP Approved Vendor
+
+The FedRAMP Marketplace serves as the central hub where federal agencies discover authorized cloud services and vendors showcase compliance status.
+
+### Listing Criteria
+
+To appear in the marketplace, you complete authorization through JAB or agency path and submit your authorization package to the FedRAMP PMO. Your listing includes authorization date, baseline level, authorizing agency, and system description.
+
+### Updating Marketplace Information
+
+As your service evolves or authorization status changes, you update your marketplace listing to reflect current information. Accurate listings help agencies make informed procurement decisions and demonstrate your commitment to transparency.
+
+### Leveraging FedRAMP Marketplace for Sales
+
+Your marketplace presence becomes a sales tool beyond federal procurement. Commercial customers increasingly reference FedRAMP as evidence of robust [security practices](https://drata.com/blog/security-frameworks), particularly in regulated industries like healthcare and finance.
+
+## Common FedRAMP Requirements Documents and Audit Artifacts
+
+FedRAMP authorization requires extensive documentation describing your system, security controls, and assessment results. Four primary documents form your authorization package:
+
+- **System Security Plan (SSP):** Comprehensive description of system architecture, data flows, security controls, and implementation details
+- **Security Assessment Plan (SAP):** Testing methodology your 3PAO uses to validate control effectiveness
+- **Security Assessment Report (SAR):** Results of 3PAO assessment, including findings and control validation
+- **Plan of Action and Milestones (POA&M):** Remediation timeline for identified vulnerabilities and ongoing risk management
+
+### System Security Plan
+
+Your SSP describes everything about your system from a security perspective—system boundaries, data flows, interconnections, user roles, and detailed explanations of how you've implemented each required security control. The SSP typically runs hundreds of pages for complex systems and requires input from security, engineering, operations, and compliance teams.
+
+### Security Assessment Plan and Report
+
+The 3PAO develops the SAP outlining exactly how they'll test your security controls, including testing procedures, sampling methodology, and expected evidence. After completing assessment, they produce the SAR documenting test results, identified vulnerabilities, and verification that controls operate as described.
+
+### Plan of Action and Milestones
+
+Your POA&M documents any vulnerabilities or control weaknesses identified during assessment and your plan for addressing them. Each item includes risk scoring, remediation timeline, and interim mitigation measures.
+
+## How Automation and FedRAMP as a Service Reduce Compliance Work
+
+Manual FedRAMP compliance creates significant operational burden—teams spend countless hours collecting evidence, tracking control status, and preparing documentation. This work diverts resources from innovation and creates risk of human error.
+
+Modern compliance automation transforms FedRAMP preparation and maintenance from manual burden into streamlined, continuous process. By connecting directly to your infrastructure and applications, automation platforms collect evidence, monitor control effectiveness, and maintain real-time compliance visibility.
+
+### Continuous Control Monitoring
+
+Automated platforms continuously verify that security controls remain in place and operate effectively, rather than relying on periodic manual checks. When a control drifts out of compliance—perhaps due to configuration change or access modification—you receive immediate alerts.
+
+### Evidence Collection Workflows
+
+Instead of manually gathering screenshots, logs, and configuration files for audits, automation platforms collect evidence continuously from your connected systems. When your 3PAO requests samples or monthly reporting deadline arrives, evidence is already organized and available.
+
+### Developer Guardrails and IaC Testing
+
+Infrastructure-as-Code (IaC) testing validates that your infrastructure configurations meet FedRAMP requirements before deployment. By scanning Terraform, CloudFormation, or other IaC templates during development, you catch compliance issues in pull requests rather than production.
+
+## Avoiding Common FedRAMP Pitfalls and Delays
+
+Organizations pursuing FedRAMP often encounter predictable challenges that extend timelines and increase costs.
+
+### Underestimating Internal Effort
+
+FedRAMP requires substantial internal resources beyond 3PAO assessment fees. You'll want dedicated staff for documentation development, control implementation, evidence collection, and ongoing maintenance. Plan for at least one full-time person focused on FedRAMP during authorization.
+
+### Misaligned Documentation
+
+A frequent audit finding occurs when security documentation doesn't match actual technical implementation. Perhaps your SSP describes a control one way, but your infrastructure implements it differently. Maintaining consistency between what you document and what you build prevents costly rework during assessment.
+
+### Inadequate Continuous Monitoring
+
+Organizations sometimes treat FedRAMP as point-in-time certification rather than ongoing compliance obligation. This leads to lapses in monthly reporting, delayed vulnerability remediation, or incomplete change management. Building sustainable processes for continuous monitoring from day one prevents compliance gaps.
+
+## Turning FedRAMP Readiness Into Customer Trust With Drata
+
+FedRAMP authorization demonstrates more than government compliance—it signals to all potential customers that you've implemented rigorous security controls and undergone independent validation.
+
+However, achieving and maintaining FedRAMP while building your core business creates competing demands on engineering and compliance resources. Compliance automation transforms FedRAMP from burden into strategic advantage.
+
+Drata automates evidence collection, control monitoring, and documentation workflows that consume the most time in FedRAMP preparation and maintenance. By connecting to your infrastructure, applications, and security tools, Drata continuously verifies control effectiveness and collects audit evidence without manual intervention.
+
+The platform's Risk Management capabilities help you track and remediate vulnerabilities identified in assessments, while Audit Hub streamlines collaboration with your 3PAO during formal evaluations. As your authorization progresses, Drata maintains the evidence trail and control monitoring that satisfies monthly reporting requirements and annual assessments.
+
+[Book a demo](https://drata.com/demo) to see how Drata helps organizations achieve FedRAMP authorization faster and maintain continuous compliance with less manual effort.
+
+## FAQs About FedRAMP
+
+### How much does FedRAMP certification cost?
+
+FedRAMP authorization costs vary based on system complexity, chosen baseline, and authorization path. Total costs typically range from $250,000 to over $1 million when including 3PAO assessment fees (typically $150,000 to $300,000), remediation efforts, internal resources, and ongoing continuous monitoring expenses.
+
+### How long does FedRAMP authorization usually take?
+
+Authorization timelines depend on your chosen path and readiness level. JAB P-ATO typically takes 12 to 18 months from initial assessment to authorization, while agency ATO often completes in 6 to 12 months. Organizations with significant security gaps may need additional months of remediation before starting formal assessment.
+
+### Who can act as a FedRAMP 3PAO?
+
+Only assessment organizations accredited by the American Association for Laboratory Accreditation (A2LA) and listed on the official FedRAMP 3PAO list can conduct FedRAMP security assessments. The FedRAMP PMO maintains this list on their website, and you select your 3PAO from accredited organizations.
+
+### Can startups achieve FedRAMP Low authorization quickly?
+
+Startups can pursue FedRAMP Low authorization more rapidly than higher baselines because Low requires fewer security controls (125 versus 325 for Moderate). However, even Low authorization typically takes 6 to 12 months and requires robust security architecture, comprehensive documentation, and dedicated resources.
+
+### Is FedRAMP required for state or local government contracts?
+
+FedRAMP authorization applies specifically to federal government cloud services and isn't required for state or local government contracts. Many state and local agencies prefer FedRAMP authorized services because the framework provides strong security validation without requiring the agency to conduct its own assessment.

Cloud DevOps/GDPR.md

@@ -0,0 +1,36 @@
+## GDPR 
+
+Summary
+
+GDPR（欧洲通用数据保护条例）学习笔记
+
+Details
+
+## GDPR基本信息
+
+- GDPR（General Data Protection Regulation）全称《欧洲通用数据保护条例》
+- 2018年5月25日在欧盟生效
+- 适用于所有在欧盟内处理欧盟居民数据的企业，包括非欧盟企业
+
+## 核心原则
+
+- 合法性与透明度：以合法、公平、透明的方式处理数据；向用户清楚披露数据用途
+- 数据最小化：只能收集必要的数据，禁止过度收集
+- 存储限制：数据只能存储必要的时间，超期数据必须删除
+- 完整性与保密性：保护数据安全，防止未授权访问或丢失
+
+## 用户权利
+
+- 访问权：用户可要求查看企业持有的自己的数据
+- 更正权：纠正不准确的数据
+- 删除权/被遗忘权：要求删除个人数据
+- 数据可携权：获取并转移个人数据
+- 反对权：反对特定的数据处理
+
+## 企业责任
+
+- 获得明确同意（非默认同意）
+- 进行数据保护影响评估
+- 实施数据保护措施
+- 72小时内报告数据泄露事件
+- 某些情况下需任命数据保护官

Cloud DevOps/Major Incident Management Process.md

@@ -0,0 +1,190 @@
+# ITOM Cloud Service Delivery : Major Incident Management Process
+
+## Introduction
+
+This document describes the process and best practices for assessing, identifying, responding, communicating, and tracking when a Major Incident occurs in a Customer Cloud environment.
+
+## Identification and Detection
+
+- **Automated Monitoring**: Utilize robust monitoring tools to detect anomalies, performance issues, and potential outages.
+- **User Reports**: Encourage users to report issues promptly via designated channels.
+
+### Best Practice
+
+- In the current Cloud service, the definition of Major Incident includes the following
+    - **Service Outage** - users cannot access the application to get any cloud services
+    - **Performance Degradation** - Performance issues are evident in the system application through monitoring and user feedback
+    - **Major Functionalities** - Currently it refers mainly to the main functions of each product monitored through APM
+
+## Initial Assessment
+
+- **Incident Triage**: Quickly assemble a cross-functional incident response team, including representatives from development, operations, and support.
+- **Impact Analysis**: Evaluate the scope and impact of the incident on users, systems, and business operations.
+
+### Best Practice
+
+- There are many ways in which we analyze incident and assess the impact on our customers.
+    - **From APM monitoring** - Major Function Service Availbility Check. Currently we have Service Availability checks defined for major features in the product. Currently the Service Center team checks and alerts this monitor 24x7. As soon as a problem occurs, it will be notified in Teams Channel. However, the probability of a False Alert on this monitor is high, so it is necessary to perform a manual validation to determine if it is a real Major Incident.
+    - **From Unified Monitoring** - Monitor Infra, K8S node, K8S pod, applicaiton with Granfa for various pre-defined levels of metrics. For Details, please refer to: [ESM Cloud Unified Monitoring](https://rndwiki.houston.softwaregrp.net/confluence/display/ICS/ESM+Cloud+Unified+Monitoring)
+    - **Confirm by Manual Validation -** Once both APM Monitoring and Unified Monitoring have alerted the system, we can also check the system manually by logging in. Team member need to save the login for each farm some monitoring tenant as quickly as possible to quickly define the problem.
+- Our goal is to determine if Farm has a S0/S1 level problem in the fastest way possible so that we can initiate the Incident Response process in the first place.
+
+## Incident Logging
+
+- **Centralized Logging**: Maintain a centralized incident log that captures all relevant details, timestamps, and initial impact assessment.
+- **Severity Classification**: Categorize incidents based on severity to prioritize response efforts.
+
+### Best Practice
+
+- Once the Major Incident has been confirmed, we need to notify the Service Center team to create a Centralized Incident in the [PPM Essential system](https://essentials.saas.microfocus.com/itg/dashboard/app/portal/PageView.jsp) as a follow-up to the RCA update as well as define Corrective Actions and Preventive Usually the Incident Manager is defined as the RCA Owner to provide detailed information.
+
+## Communication
+
+- **Internal Communication**: Establish communication channels for the incident response team, ensuring timely updates and coordination.
+- **External Communication**: Prepare predefined messages for customers and stakeholders, providing transparency about the incident.
+
+### Best Practice
+
+**Internal Communication:**
+
+- Create a new Teams chat group in time and add relevant stakeholders to bring attention to major incidents in time for better support. 
+- Relevant stakeholders include:
+    - Incident Manager: Can be a Cloud team lead or Senior team member, this role will be coordinated and directed in the event of an incident.
+    - CORE CPE Engineer: CORE CPE engineers will follow up with customers' incident-related tickets and respond to customers' related questions in a timely manner.
+    - Cloud Ops Engineer 
+    - RnD Emergency Contact
+- Internal communication is very important in order to save time and get all the relevant people involved in Incident's support.
+
+  
+
+**External Communication:**
+
+- When a major incident occurs, we should communicate with the customer as soon as possible in order to keep them up to date.
+- There are currently two main types of communication
+    - Send notification to specified customer groups via PCS. For details, please refer to - [Send email notification to SaaS customers via PCS](https://confluence.opentext.com/display/ICSD/Send+email+notification+to+SaaS+customers+via+PCS)
+    - Publish Incident Report in SaaS Service Health Page.  For details, please refer to - Operation guide for SaaS Service Health Page
+- It is best to follow the given format when posting a incident notificaiton: [Major Incident Customer Communication Template](https://rndwiki.houston.softwaregrp.net/confluence/display/ICS/Major+Incident+Customer+Communication+Template)
+
+## Resolution
+
+- **Runbooks and Playbooks**: Develop detailed runbooks and playbooks for common incident scenarios, outlining step-by-step resolution procedures.
+- **Escalation Procedures**: Define clear escalation paths for issues that require higher-level expertise or management attention.
+
+### Best Practice
+
+- The Cloud Service team has developed a detailed runbook to address some of the most common problems, which allows you to choose the appropriate way to recover services for different types of false alarms. For details, please refer to: [Alert Runbooks based on monitoring](https://rndwiki.houston.softwaregrp.net/confluence/display/ICS/Alert+Runbooks+based+on+monitoring)
+- If the service is still not restored properly through the existing runbook, we need to immediately involve RnD engineers through a pre-defined escalation path. 
+
+## Post-Incident Review (PIR)
+
+- **Root Cause Analysis (RCA)**: Conduct a thorough RCA to identify the underlying cause of the incident.
+- **Documentation**: Document the incident resolution process, lessons learned, and preventive measures for future incidents.
+
+### Best Practice
+
+- The current best pratices are for each major incident, Cloud service team will create a wiki page to track some important information, such as what important changes have been made during the incident, the focus of the discussion. Preventive actions planned for the future. For example: [2023/11/08 - EU8 - SMAX- Service Outage](https://rndwiki.houston.softwaregrp.net/confluence/pages/viewpage.action?pageId=1278257525)
+- In addition, we will also track each major incident, and clearly define the Owner. [ESM Cloud Incident Tracking List](https://rndwiki.houston.softwaregrp.net/confluence/display/ICS/ESM+Cloud+Incident+Tracking+List)
+- The Cloud Service team will drive these processes as the primary Incident Owner.
+- Once the relevant Corrective Actions and Preventive Actions have been defined, the Cloud Service team's Incident Owner needs to record the CAPA information into the Major Incident in PPM Essential for ongoing tracking. For details, please refer to: [Incident Report and Actions from RCA Owner on Essentials.pdf](#)
+
+## Continous Improvement
+
+- **Iterative Updates**: Regularly update incident response procedures based on lessons learned from past incidents.
+- **Training and Drills**: Conduct regular training sessions and simulated drills to ensure the incident response team is well-prepared.
+
+### Best Practice
+
+- We regularly hold updated training sessions to enhance the team's understanding of the Major Incident process and to share best practices.
+
+## Monitoring and Alerting Ehancements
+
+- **Continuous Monitoring**: Implement ongoing improvements to monitoring and alerting systems to proactively detect potential issues.
+- **Automated Remediation**: Integrate automated remediation tools to address common incidents swiftly.
+
+### Best Practice
+
+- Adjust monitoring metrics in a timely manner to reduce the probability of a FALSE ALERT. We need more accurate and effective monitoring to catch problems.
+
+## Documentation and Knowledge Sharing
+
+- **Knowledge Base**: Maintain a comprehensive knowledge base with troubleshooting guides, FAQs, and resolutions for known issues.
+- **Documentation Accessibility：**Ensure that incident response documentation is easily accessible to all team members.
+    
+
+### Best Practice
+
+- We need to keep improving the runbook so that there is a consistent way for team members to monitor all levels of issues and resolve them. [Alert Runbooks based on monitoring](https://rndwiki.houston.softwaregrp.net/confluence/display/ICS/Alert+Runbooks+based+on+monitoring)
+
+## Review and Audit
+
+- **Periodic Audits**: Conduct periodic reviews and audits of the major incident management process to identify areas for improvement.
+- **Compliance Checks**: Ensure that the process aligns with industry best practices and regulatory requirements.
+
+### Best Practice
+
+- We need plan the regularly conduct Major Incident rehersal to ensure that team members are familiar with the process and the importance of division of labor.
+
+  
+
+## Training Record:
+
+[https://opentextcorporation-my.sharepoint.com/:v:/g/personal/wshen_opentext_com/EaP0NtIYS1pCn3LWaMDkpMMBX5AVF2HOQlMos7L39PMRaA?referrer=Teams.TEAMS-ELECTRON&referrerScenario=MeetingChicletGetLink.view.view](https://opentextcorporation-my.sharepoint.com/:v:/g/personal/wshen_opentext_com/EaP0NtIYS1pCn3LWaMDkpMMBX5AVF2HOQlMos7L39PMRaA?referrer=Teams.TEAMS-ELECTRON&referrerScenario=MeetingChicletGetLink.view.view&isSPOFile=1)
+
+  
+
+  
+
+## Introduction
+
+Contents
+
+- [Introduction](#MajorIncidentManagementProcess-Introduction)
+- [Identification and Detection](#MajorIncidentManagementProcess-IdentificationandDetection)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice)
+- [Initial Assessment](#MajorIncidentManagementProcess-InitialAssessment)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.1)
+- [Incident Logging](#MajorIncidentManagementProcess-IncidentLogging)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.2)
+- [Communication](#MajorIncidentManagementProcess-Communication)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.3)
+- [Resolution](#MajorIncidentManagementProcess-Resolution)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.4)
+- [Post-Incident Review (PIR)](#MajorIncidentManagementProcess-Post-IncidentReview\(PIR\))
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.5)
+- [Continous Improvement](#MajorIncidentManagementProcess-ContinousImprovement)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.6)
+- [Monitoring and Alerting Ehancements](#MajorIncidentManagementProcess-MonitoringandAlertingEhancements)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.7)
+- [Documentation and Knowledge Sharing](#MajorIncidentManagementProcess-DocumentationandKnowledgeSharing)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.8)
+- [Review and Audit](#MajorIncidentManagementProcess-ReviewandAudit)
+    - [Best Practice](#MajorIncidentManagementProcess-BestPractice.9)
+- [Training Record:](#MajorIncidentManagementProcess-TrainingRecord:)
+- [Introduction](#MajorIncidentManagementProcess-Introduction.1)
+
+Document Information
+
+|   |   |
+|---|---|
+|**Product:**|ESM|
+|**Applicable Product Version:**|All Vesions|
+|**Document Author:**|[Wei Shen](https://rndwiki.houston.softwaregrp.net/confluence/display/~wei.shen2@microfocus.com)|
+|**Created Date:**|13 Dec 2023|
+|**Reviewed By:**||
+|**Reviewed Date**||
+|**Approved By:**||
+|**Approved Date:**||
+|**Document Authority:**|CLOUD OPS RND|
+
+Change History
+
+|Version|Published|Changed By|Comment|
+|---|---|---|---|
+|**[CURRENT](viewpage.action?pageId=686083938) (v. 2)**|Jul 09, 2025 16:54 EDT|**[Scott Deyarmond](/display/~sdeyarmond)**||
+|[v. 1](viewpage.action?pageId=710776398)|Jan 23, 2025 03:38 EST|**[Yun Zhao](/display/~yzhao3)**||
+
+**Related pages**
+
+**Content by label**
+
+There is no content with the specified labels

Cloud DevOps/SOC2 Audit in Practice.md

@@ -0,0 +1,181 @@
+## Security
+### Access Control
+
+**AWS Account Access Review**
+现在来说一下 SOC2 audit 在我们实际的工作当中是怎么样来执行的。先开始第一个：security 里
+面的 access control。讲的例子主要是我们要怎么样来管理 AWS account 的 access control。因为我作为整个 cloud service delivery 的 manager，所以我管理了差不多有 23 个 AWS account。我是这些 AWS account 的 account owner。所以我会每个季度进行一次 quarterly review 来检查这些 account 里面访问的用户的一些权限，包括检查一些已经离开公司的人员是否还有访问权限。先我们在 AWS account 里面事先会设计不同的 IAM 角色，然后给这些角色赋予不同程度的权限。比如 operation team 的 member 的权限比较大，因为他要在 AWS 上面去操作很多资源来进行一些升级，包括一些网络的修改等等。
+
+其次我们还有一些 DevOps 团队。这些团队其实有些是 Network Team，有一些是 CCOE Team，他负责的是一些操作系统的 AMI的更新。所以他们的权限相对来说比 operations 要稍微小一点，主要集中在他们所对应的相关领域里面。我们还设计了一些 read-only 的权限，这个主要是给到一些 architect。他们可能要在我们的环境里面去抓取一些相关信息，但是他们不允许在我们的 AWS account 里面做一些修改，所以我们会设定一些 read-only 的政策。当然，这个里面权限设定会比较复杂，还有其他各种各样的权限都是根据不同的角色来设定的。你的操作方法呢是：我们每三个月会从整个 AWS account 的 primary owner 那边去拿到一个 account 的 access list。因为我们的 AWS account 访问是和 company 的 single sign-on 绑定的，所以我们是通过 email authentication 来登录 AWS account。所以这些信息会在更高级别的这个 IT 团队里面有，访问具体某个 AWS account 的 user 的一个 list。我拿到了过去3个月的访问记录以后，我会逐个地对这些人员进行分类：
+- operation 团队的人
+- devops 的
+- 其他的 architect group 的
+分好类以后我会检查他们所对应的权限。如果出现一些人员我并不认识或者是我并不组织的，我会发给相应的 devops 的 manager 以及 architect 的 group 的 manager，请他们帮忙来进行确认。 包括我自己的 operation 团队，我也会检查所有人员是否是当前在职人员。如果有一些人员已经离职了，但是他的访问权限还出现在这个 access list 里面，那我们就必须采取行动立即停止这些访问权限。 这个动作称之为“calibrate  access write”。
+当我完成了每三个月一次的 access review 以后我会做一个 summary report，然后把这个 report 发给我的 director、manager，甚至高级别的 high-level manager，来进行 sign-off，来确认我们完成了这样的一个动作。
+
+在这个过程当中所有最初的原始人员的名单、我进行 calibrate 的 report，以及我去跟其他的 manager 进行确认的沟通邮件，都会被记录下来作为 evidence，来应对后续的 SOC2 audit。 
+
+**Restrict to access product source code repository**
+还有一个项目也是会定期来做检查的。这个的目的也是从安全的角度考虑。在我们现在的这个组织里面我们是不允许 operation 的管理员有权限去访问整个产品的 source code repository 的。
+
+operation 它应该不应该去放到 product 的 source code 不能做任何的 code commit 来修改产品里面的任何一些逻辑，包括一些安全方面的东西。它是不能涉及到这个 source code 的。所以在这个地方我们也有额外的 check：我们会检查我们的 GitLab 的权限，确保我们的 operation engineer 没有任何权限去访问我们的 source code 的这些 repository。 
+地方呢，我们会找到相应的 product team 的 owner、manager，作为这些 code repository 的 owner。我们会要求他能够提供这么一个名单，然后我们会来检查我们的 operating ID 是否在这个名单里面。正常的应该不在那个名单里面。
+
+如果我们发现有些工程师是有权限可以访问的，我们会做一些 cataloger 去把这些权限可能拿掉。同样的整个过程当中所有的记录，原始的记录包括 cataloger 的记录，以及后续的一些 summary 的 report，都会保存下来，也会给high level manager sign off。 
+
+**Risk Assessment**
+
+
+**Vulnerlubility Management**
+这里介绍的是一个关于 vulnerability 的管理。我的介绍的 case 是我们的商业应用在云上的环境下面，我们定期会有 security 的 scan。其中就有 Qualys 的 scan 和 Prisma Defender 的一些 scan。
+
+Qualys 的 scan 主要是针对我们 Cloud Application Runtime 环境上面的操作系统，比如 Linux，包括会有哪些 risk 和一些漏洞，这些都会被 Qualys 进行扫描出来。我们是这样来进行管理的。
+
+作为整个 account 的 owner，我会定期收到系统发出的一些 policy report。这些 report 的内容会非常大，涉及整个 OS 里面的很多方方面面的一些 vulnerability。我们会对这些问题进行 filtering。首先我们会根据里面一些问题的 severity 来进行 filtering，来分析哪些是 OS 级别的。我们会结合我们另外一个 branch，那是我们整个 cloud central excellence team 提供的持续的 OS 级别的 Linux AMI hardening。
+
+最早我们一开始使用的是 AWS 原生的 Linux hardening。后期因为各种客户的需要，包括我们有一些 specific 的 security requirement，我们就开始 adopt CCOE 提供的标准 Linux AMI。它发布的周期差不多是每个月发布一个新的版本，包含最新的 patch。我们会在收到他们测试过的 AMI 之后来进行 project plan。 除了通过AMI的升级能够修复一些OS级别的问题之外，我们还会定义我们还会 filtering 一些是不是通过OS升级来发现的那些问题。
+
+针对这些问题我们就需要去做一些额外的动作。有可能我们会要去通知 product team 升级某些 library 的版本。如果一些旧的版本包含了一些 vulnerability 的问题的话，我们需要去联系研发团队、开发团队去更新这样的 library。
+
+最终我们会定义一些 plan：哪些问题我们会在下一个版本进行修复。当我们升级完 AMI，包括开发团队也提供了相应的一些产品补丁之后，我还会针对这个最新的 policy 来和之前的 review 进行一次比较。看看哪些问题可以标注为已经修复了，哪些问题其实还是没有修复呢。如果有些问题并没有完全修复，我们会 highlight 出来，然后再进一步制定一些新的计划。计划还是根据整个扫描出来的问题的 severity 来进行下一步的新的计划。
+
+比如之前Qualy扫描出来的有些问题是由于 Kubernetes 的版本太低造成的。我们就需要计划在下一个版本中对 AWS 上面的 EKS 的版本进行升级来解决这个问题。
+
+像类似的这种问题我们都会进行检查，并把所有的发现、filtering、review，包括后续 fix、testing、sign off，这些所有的内容整个过程全部都记录下来，以便以后进行后续的 software audit。 
+
+## Availbility
+- **Backups**
+	针对我们 SaaS application 的 backup，我们基本上是 90% 依赖于 AWS 原生的一些 cloud-native backup feature。
+	
+	比如说我们的 application 首先是基于 AWS EKS 整个进行 Kubernetes 容器化部署的。所以在备份过程当中整个 cloud application 的备份，我们并不是要备份所有这些庞大的 images，因为这些 images 通过 R&D 团队每个版本发布到 GitHub 上面去的。
+	
+	唯一我们需要备份的其实是 Kubernetes 的一些 configuration files。这样的话我们可以通过 configuration files（那些 yaml 文件）能够快速地把整个 web application 整个容器化，包括它的 pod 分布和 work node 的分布。我们可以很快地按照这个 configuration 还原出来。
+	
+	所以我们只要备份一些 configuration files 就可以了。数据库RDS和数据存储EFS这方面我们是依赖 AWS backup。 这个 AWS  backup，我们是会制定一系列的 backup plan，包括了整个备份的频率。我们每 6 个小时会对 RDS/EFS 的整个数据库和数据存储进行一次备份。这个备份不仅仅是备份到当前的 region；同时我们会通过一些额外的脚本来实现把 RDS 能够备份到一个remote region: 
+	AWS Oregon -> AWS North Viginia
+	AWS Frankfult -> AWS Ireland
+	
+	然后我们整个数据保留 7 天。这个 backup 是根据我们对整个 disaster recover 的一个 commitment 来做到的。RPO/RTO 我们在 SaaS 的一个 service description 里面是提到的，我们会把数据的影响控制在大概 6 个小时之内。
+- **Processing Capacity**
+- **Replication**
+
+	- **数据复制**：在多个系统/地域间同步数据副本，确保即使主系统故障，数据仍可被访问
+	- **实时或准实时的备份机制**，避免单点故障导致数据丢失
+	- **恢复时间目标（RTO）的支撑**：通过即时可用的副本，快速切换到备用系统
+	我们每 6 个小时会对 RDS 的整个数据库进行一次备份。这个备份不仅仅是备份到当前的 region；同时我们会通过一些额外的脚本来实现把 RDS 能够备份到一个remote region: 
+	AWS Oregon -> AWS North Viginia
+	AWS Frankfult -> AWS Ireland
+
+	到的这个方案基本上还是属于一个 cold backup、远备份的方案，因为是考虑到一些成本的原因。其实在这个基础上我们还有一套更快速能够缩短整个 RTO 时间的预案，我们称之为一个热备份方案。
+
+那个方案基本上是会把 RDS 和 EFS 这些 snapshot 在另一个 Viginia 的 AWS 环境里面定时地直接恢复到这个数据库里面，而不是以 snapshot 的形式存在。这样做虽然我们并不是说真正去启一套 runtime 的 instance，但是它可以大大缩短我们在另外一个 region 恢复整个 cloud 的状态所需的时间。这样的话这个成本会相对来说有所提高。
+
+在这个方面我们会根据客户一些不同的要求来进行取舍。
+
+	
+- **Multi-location Strategies**
+	
+
+
+- **Business Continuity Planning and Testing**
+- **Disaster Recovery Planning and Testing**
+我们一年会进行两次DR testing，我们称之为 disaster recovery integrity testing。测试一次是轻量级的，不影响生产环境的，只是验证数据完整性的测试。那另一次就相对来说更复杂一点，它是一个完全DR的测试。 
+是针对我们的 backup 的数据。这里面包含了 device 的 configuration file 和我们的 RDS 数据的备份。根据这些内容在我们一个 backup 环境里面恢复备份数据。这个 backup 环境跟生产环境在同一个 region 但是不影响正常环境。
+
+我们去利用备份数据恢复一套账，看整个恢复需要多长时间，但是这个恢复不切换生产环境。
+
+第二次测试我们会 test 这个 remote 的  backup。因为我刚才提到了，在备份过程中我们会把数据备份到另外一个 remote region。我们利用这些 remote region 的 backup data 去 restore 整个 instance，然后这个是要配合在生产环境。
+
+我们基本上是要在周末做停机切换：会把生产环境停掉，然后拿最新的 backup 的 delta 来恢复 remote region 的一个 instance。恢复好了以后我们会把整个生产环境的流量切换到新的 remote region 的环境下面，再恢复整个数据的流量，让客户能够使用。基本上是在一个星期之后，我们把数据反向恢复到我们原来的旧生产环境当中，再做一次服务压力测试，给它切换回去。
+
+这个对我们的要求会比较高。 
+
+抵押的标准要求是按照我们在 SAS service description 里面给用户的承诺：RPO 和 RTO。 Recovery product objective 是 6 小时，recovery time objective 是 24 小时。这个策略也是根据这个标准来执行的。
+
+## Confidentialty 
+- **Confidential Information Classification**
+- **Confidential Information in Non-Production Environments**
+针对这一块的 software audit，我们主要是用来证明我们在测试环境方面有专门的 staging，用于测试 application 的 upgrade，包括一些 patch、hotfix 的 deployment，以及我们在调整 cloud infrastructure 的结构上面的一些部署。包括一些自动化的测试都是在 staging 环境上面进行测试的。
+
+这个的目的就是要测试我们在 staging 的环境上面没有用到大数据上面的 custom、confidential 的一些数据。这个主要的证明方法其实就是我们提供相应的 staging form 上面一些 tenant 的名称，包括做一些实际的演示，来证明我们仅仅只用到了一些测试的数据，并没有用到真实的客户的数据；也绝对不会包含 PII 个人信息的一些内容。 
+
+- **Data Deletion and Removal Practices**
+		Customer Exit Process:
+				## Introduction
+		
+		When a SaaS customer decides to leave, it's crucial to handle the transition smoothly and professionally to ensure a positive experience, which can impact future business opportunities and the company’s reputation. This document describes the main processes and actions regarding customer exits.
+		
+		## Service Description about Service Decomission
+		
+		Service Decommissioning  
+		Upon expiration or termination of the SaaS Order Term, Micro Focus may disable all Customer access to  
+		SaaS, and Customer shall promptly return to Micro Focus (or at Micro Focus’s request destroy) any  
+		Micro Focus materials.  
+		Micro Focus will make available to Customer any SaaS Data in Micro Focus’ possession in the format  
+		generally provided by Micro Focus. The target timeframe is set forth below in Termination Data  
+		Retrieval Period SLO. After such time, Micro Focus shall have no obligation to maintain or provide any  
+		such data, which will be deleted in the ordinary course.
+		
+		### **Communication and Coordination**
+		
+		- **Notify Relevant Teams**: Inform all relevant internal teams (support, billing, account management, cloud service etc.) about the customer's decision.
+		- **Designate a Point of Contact**: Assign a single point of contact to manage the transition and ensure all queries are addressed promptly. Usually it's the CSM.
+		
+		### **Data Management**
+		
+		- **Data Backup and Export**: Ensure the customer can export their data easily. Provide assistance if necessary.
+		- **Data Deletion**: Plan for secure deletion of the customer’s data from your servers after a certain period, in compliance with data protection regulations and your data retention policy.
+		- **Data Access Period**: Provide a clear timeline for how long their data will remain accessible after service termination.
+		
+		### **Security and Compliance**
+		
+		- **Revoke Access**: Ensure all user accounts associated with the customer are disabled and access to the system is revoked.
+		- **Compliance Check**: Ensure that the termination process complies with all relevant legal and regulatory requirements, such as GDPR or CCPA.
+		
+		## Detailed Steps for customer exit
+		
+		### Customer to submit service request to trigger customer exit project
+		
+		The customer needs to submit a service request in PCS to start the customer exit process. All related communication will be still handled in PCS until all the tasks are done and close the user account in PCS.
+		
+		- In the request, the customer needs to clarify the following specific needs:  
+		    Whether they wish to export existing ESM/SMAX transaction data?  
+		    What's the expected date customer want all tenant data to be emptied out completely?  
+		    What's the exact date Opentext to commit all relevant date (including backup data) will be cleaned out completely?  
+		    What's the exact data to close PCS support channel?
+		
+		### Assist with data export
+		
+		- What’s the suggestion to customer to export data?
+		    - SMAX
+		        - SMAX Offer customer to use OData export to export data
+		            - Cloud Ops team can help to use existing OOTB OData export script to export SMAX transaction data per tenant
+		    - CMS/HCMX/OO
+		        - Not support by now
+		    - PCS data
+		        - No Support by now
+		
+		### Plan data deletion
+		
+		- Notification to customer to notify when we will terminate the tenant and delete all data
+		    - Cloud Ops will handle such notification from PCS.
+		- Scope of data deletion
+		    - Tenant data/user data/ account data (in BO)
+		    - Inactive PCS entitlement 
+			- Data retention- farm level data retention is only 7 days. After 7 days customer data will permanently removed from Cloud environment
+## Processor Integrity
+[[Major Incident Management Process]]
+[[Cloud Change Management Process]]
+
+## Privacy
+**Data Controller**
+在这个方面我们实际的操作过程当中是的确有这样的一个需求的。我们管理的所有环境当中有两个比较特殊的环境：
+
+- 在美国的一个 instance，因为它是要符合 FedRAMP 整个标准规范的。因此他对所有能够接触到数据的工程师有这样的要求：只有在美国当地的美国公民才能去 touch 这个环境里面的所有数据。因此我们在做数据控制方面会特意规避这样的要求。我们只允许美国的 operation 工程师能够操作、访问以及维护这一套环境上面所有的数据。包括在其他国家的中国、印度以及在欧洲的工程师都没有权限去 touch 这个数据。
+- 在欧洲的环境，它是要符合欧盟的一些规范，包括一些 GDPR 的要求。同样地，只允许欧洲的工程师访问；其他 region 的工程师都不能访问那几个特定的环节。
+
+[[GDPR]]
+[[FedRAMP Basics Understanding Federal Cloud Security Standards]]
+
+
+
+

Cloud DevOps/SOC2_Compliance_Summary_EN.md

@@ -0,0 +1,413 @@
+# SOC 2 Compliance Training Course - Transcription Summary
+
+## 【Chapter 1】SOC 2 Compliance Fundamentals
+
+### Core Information
+- SOC 2 is a third-party audit framework validating that a company has security controls in place
+- Primarily used for B2B business partnerships to establish trust and security validation
+- Governed and standardized by AICPA (American Institute of Certified Public Accountants)
+- Has become the market default requirement for SaaS and cloud platform companies
+- Understanding SOC 2 eliminates compliance confusion and prevents wasted effort
+
+### Key Terms and Definitions
+- **Service Organization**: The company/customer undergoing the SOC 2 audit
+- **Service Auditor**: The CPA who performs the SOC 2 examination according to AICPA standards
+- **User Entities**: The customers receiving and reviewing the SOC 2 report
+- **Subservice Organizations**: Organizations that perform controls on behalf of the service organization (e.g., AWS, GCP, Azure)
+- **Trust Services Categories (TSCs)**: The five pillars against which companies are evaluated
+  - Security (安全性)
+  - Availability (可用性)
+  - Confidentiality (保密性)
+  - Processing Integrity (处理完整性)
+  - Privacy (隐私)
+
+
+## 【Chapter 2】Why Companies Pursue SOC 2
+
+### Core Information
+- Customer demand is the primary driver (mandatory in contracts/RFPs)
+- SOC 2 is an "audit once, use many" solution
+- Compliance with regulatory requirements and industry-specific demands
+- Serves as a market differentiation and marketing tool
+- SOC 2's flexibility allows for customized control measures tailored to your organization
+
+### Detailed Breakdown
+
+#### Business Drivers
+- **Customer Demand**: Common requirement in contracts and RFPs; often blocks business deals
+- **Sales Department Focus**: SOC 2 reports are used to close deals and increase revenue
+- **Audit Once, Use Many**: One report responds to multiple customers' security inquiries instead of responding to different requests from each new customer
+- **Competitive Differentiation**: Demonstrates maturity and robust cybersecurity program to stand out from competitors
+
+#### Regulatory and Compliance Factors
+- Industry-specific requirements (HIPAA, PCI DSS, etc.)
+- Regulatory mandates or breach fines
+- Investor due diligence requirements
+
+#### Flexibility Advantages
+- Unlike prescriptive frameworks like PCI DSS and ISO 27001, SOC 2 is not prescriptive
+- Companies are not told exactly what to do, just what criteria or control objectives to meet
+- Allows for customized controls tailored to your specific company and application
+- Makes SOC 2 reports more robust and valuable to report readers
+- This flexibility is a vital competitive advantage
+
+
+## 【Chapter 3】SOC 2 Report Distribution and Use
+
+### Core Information
+- SOC 2 reports are restricted use reports (50+ pages with sensitive control details)
+- Must be shared via Non-Disclosure Agreements (NDA) with specific parties
+- SOC 3 is the public version of SOC 2 Type 2 reports
+- AICPA logo can be publicly displayed on websites (no NDA required)
+- SOC 2 Plus allows integration of other compliance frameworks (HIPAA, ISO 27001, etc.)
+
+### Detailed Breakdown
+
+#### SOC 2 Report Sharing
+- **Restricted Use Report**: Contains sensitive control and audit details
+- **Specific Purpose Distribution**: Used for vendor due diligence or investor due diligence
+- **NDA Protection**: Requires non-disclosure agreements between companies
+- **Administrative Burden**: NDA process is tedious, but automated tools exist to simplify it
+
+#### Public Promotion Options
+- **AICPA SOC 2 Logo**: Complete simple application (<10 minutes) to publicly display the official logo
+- **SOC 3 Reports**: Trimmed-down versions of SOC 2 Type 2 reports with sensitive details removed (Sections 3 and 4)
+- **SOC 3 can be publicly posted on websites for marketing purposes**
+
+#### SOC 2 Plus Reports
+- Combines SOC 2 + HIPAA, ISO 27001, PCI DSS, or other frameworks
+- Satisfies multiple compliance framework requirements with one audit
+- Service auditor performs tests for all controls in additional frameworks
+- Increases effort but saves time and cost compared to separate audits
+
+### Action Items
+- Establish NDA process or use automated tools for report sharing
+- Apply for AICPA logo to display on company website
+- Evaluate if SOC 2 Plus or SOC 3 reports are needed
+
+
+## 【Chapter 4】SOC 2 Report Types
+
+### Core Information
+- SOC 2 Type 1: Point-in-time design assessment (fast, low cost)
+- SOC 2 Type 2: 12-month operational effectiveness assessment (target type, most commonly required)
+- 90% of contracts require Type 2 reports
+- Type 1 is a stepping stone to Type 2 (crawl, walk, run principle)
+- Sample testing is used in Type 2 to verify control consistency throughout the period
+
+### Detailed Breakdown
+
+#### SOC 2 Type 1
+- **Point-in-Time Assessment**: Controls evaluated as of a specific date
+- **Design and Suitability Focus**: Verifies controls are in place but NOT that they operate effectively
+- **Low Evidence Requirements**: Only one example needed (e.g., one employee completing training)
+- **No Test Steps or Results**: Section 4 only lists controls
+- **Significantly Lower Effort**: Much less work compared to Type 2
+- **Fast Path**: Quickest way to achieve SOC 2 compliance
+
+#### SOC 2 Type 2
+- **Time Span**: Typically 12 months, but can range from 3-12 months
+- **Operational Effectiveness Focus**: Verifies controls operated effectively throughout the entire period
+- **Backward-Looking Assessment**: Auditor looks at controls over a prior period
+- **Sample Testing Methodology**: Auditor uses random selection to test a representative sample
+  - Example: From 100 new hires during the audit period, auditor tests a random sample rather than all 100
+- **Detailed Test Steps and Results**: Section 4 includes test steps and their results
+- **Significantly Higher Effort**: Much more work for both auditor and company being audited
+- **Annual Renewal Expected**: Customers expect Type 2 reports to be renewed each year
+
+### Action Items
+- First Audit: Conduct Type 1, then move to Type 2 (follow crawl, walk, run principle)
+- Third-Party Verification: Verify controls are in place before evaluating operational effectiveness over time
+
+
+## 【Chapter 5】SOC 2 Report Structure Analysis
+
+### Core Information
+- SOC 2 reports contain 5 main sections + 1 optional section
+- Section 1: Auditor's Opinion (pass/fail determination point)
+- Section 3: System Description (most important detailed information)
+- Section 4: Controls and Test Results
+- Section 5: Optional management response and framework mapping
+
+### Detailed Breakdown
+
+#### Section 1: Independent Service Auditor's Report - The Opinion
+- **Opinion Types**:
+  - Unqualified Opinion: Perfect pass, no issues found
+  - Qualified Opinion: One or more issues identified
+  - Adverse Opinion: Significant issues found (very rare)
+  - Disclaimer of Opinion: Unable to audit
+- **Most Common**: Unqualified opinions are most common, but qualified opinions are not rare
+- **Exception Definition**: When auditor finds a control not operating effectively
+  - Examples: Employee didn't complete security awareness training; employee with sensitive data access lacks MFA
+- **Reader Guide**: This is where you determine if the company passed or failed SOC 2
+
+#### Section 2: Management's Assertion
+- Management confirms that the description of systems and controls provided is accurate and complete
+- Management acknowledges design and operational effectiveness (for Type 2)
+- Must be signed by company leadership (CEO, CTO, etc.)
+- Demonstrates company ownership and responsibility for the audit
+
+#### Section 3: System Description (Most Important Section)
+9 Description Criteria (DC1-DC9):
+
+- **DC1 - Overview of Services Provided**: Brief overview of services (must be objective facts, not marketing language)
+- **DC2 - Principal Service Commitments and System Requirements**: Customer contract commitments related to in-scope TSCs
+- **DC3 - System Components**: Technical details including:
+  - Hosting location (AWS/GCP/Azure, etc.)
+  - Software tools used
+  - Infrastructure, software, people, procedures, and data
+  - ✓ Best section to quickly understand company tech stack
+- **DC4 - Events Not Aligning with Service Commitments**: Description of incidents failing to meet commitments (e.g., outages) and remediation
+- **DC5 - Control Activities**: Narrative description of controls evaluated
+- **DC6 - Complementary User Entity Controls (CUEC)**: Controls users should have in place
+  - Example: Users must notify the company to remove access of terminated employees
+- **DC7 - Complementary Subservice Organization Controls**: Controls third parties should have (shared responsibility model)
+- **DC8 - Non-Applicable Criteria**: Standards not applicable to the organization
+- **DC9 - Significant Changes to the System**: Major system changes during the period (Type 2 only)
+
+✓ **Critical Tip**: Read Section 3 to verify the SOC 2 covers services relevant to your organization
+
+#### Section 4: Trust Services Criteria and Related Controls
+- **Type 1**: Lists controls only
+- **Type 2**: Lists controls + test steps + test results
+- **Exceptions and Deviations**: When auditor finds a control not operating effectively
+  - Example: During sampling, auditor discovers one employee didn't complete required training
+  - Type 2 Focus: Review any controls with exceptions and assess the risk
+
+#### Section 5: Other Information Not Covered by Auditor's Report (Optional)
+
+Two Common Uses:
+
+1. **Management Response to Exceptions**:
+   - Background information about identified issues
+   - Remediation steps taken by the company
+   - Explanation of how the exception is not systemic
+
+2. **Mapping to Other Frameworks**:
+   - Map SOC 2 controls to HIPAA, ISO 27001, PCI DSS
+   - Help industry-specific customers understand framework relevance
+   - Example: Healthcare companies showing HIPAA compliance alignment
+
+✓ Not audited by third party; management's responsibility
+✓ Framework mapping helps sales in specific verticals
+
+
+## 【Chapter 6】Trust Services Categories (TSCs) - Scoping
+
+### Core Information
+- TSCs are the pillars of evaluation (choose from 5 categories)
+- Scoping Decision Principle: **Base decisions on customer commitments**
+- Look for commitments in customer contracts, SLAs, and MSAs (For example: Uptime Commitment: 99.9%)
+- Don't include categories just to include them; cost and effort increase significantly
+
+### Detailed Breakdown
+
+#### Selection Process
+1. Review customer contracts/SLAs/MSAs for commitments
+2. Identify which TSCs align with these commitments
+3. Ensure you have documented commitments for each in-scope TSC
+
+### Key Terms and Definitions
+- **Commitment**: Pledges made to customers in contracts, service level agreements, master service agreements, or terms and conditions
+- **Scoping**: The process of choosing which TSCs to include in your SOC 2 audit
+- **In-Scope**: TSCs and controls that are part of your SOC 2 audit
+
+### Action Items
+- Review all customer contracts for security-related commitments
+- Identify commitments related to each potential TSC
+- Document which TSCs align with your actual business commitments
+- Avoid including TSCs without corresponding commitments
+
+
+## 【Chapter 7】Security TSC (Security Trust Services Category)
+
+### Core Information
+- Almost every SOC 2 includes the Security category
+- Security is the foundation and minimum requirement
+- Contains 9 Common Criteria (AICPA standard baseline)
+- Typical control count: 40-50 controls
+
+### Detailed Breakdown
+
+#### Covered Security Topics
+- Onboarding and Offboarding
+- Risk Assessments
+- Vulnerability Management
+- Access Control
+- Information Security Policies and Procedures
+- Vendor Management
+- Other foundational security practices
+
+#### Best Practices
+- Early-stage startups can achieve SOC 2 with Security category alone
+- Commonly paired with Availability and Confidentiality (3-category combination is very common)
+- 50% of SOC 2 reports include Security + Availability + Confidentiality
+
+
+## 【Chapter 8】Availability TSC
+
+### Core Information
+- Common for cloud-hosted companies (cloud provider features support native capabilities)
+- Only include if you have availability commitments
+- Smallest control count: 8-10 controls
+- Contains 3 criteria (vs Security's 9)
+
+### Detailed Breakdown
+
+#### Covered Availability Topics
+- Backups
+- Processing Capacity
+- Replication
+- Multi-location Strategies
+- Business Continuity Planning and Testing
+- Disaster Recovery Planning and Testing
+
+#### Advantages
+- Cloud provider default features make evidence provision easy
+- Natural choice for cloud-native companies
+
+#### Common Combinations
+- 50% of SOC 2 reports include Security + Availability + Confidentiality
+- Especially common in early-stage startups
+
+### Action Items
+- Don't include this category just because you're on the cloud
+- Always base decisions on actual commitments
+- Verify you have documented availability commitments before including
+
+
+## 【Chapter 9】Confidentiality TSC
+
+### Core Information
+- Key Question: How do you handle customer data when they leave your service?
+- Focus: Data classification and secure data handling
+- Control count: 4-8 controls
+- Contains 2 criteria
+
+### Detailed Breakdown
+
+#### Covered Topics
+- Confidential Information Classification
+- Confidential Information in Non-Production Environments
+- Data Deletion and Removal Practices
+
+#### When to Include
+- If your MSA commits to deleting all customer data within X days of contract termination
+- If you make commitments about data handling during customer termination/offboarding
+
+#### Implementation Challenges
+- Data deletion and removal practices are difficult to execute correctly
+- Must establish and mature these processes before the audit
+- Don't underestimate implementation difficulty
+- This is not an easy add-on
+
+### Action Items
+- Review data deletion commitments in customer contracts
+- Establish and test data deletion procedures before audit
+- Ensure processes are mature and consistent
+- Verify deletion procedures for all data types
+
+
+## 【Chapter 10】Processing Integrity TSC
+
+### Core Information
+- Common Misconception: NOT the "I" in CIA triad (data integrity)
+- Focus: **Completeness and accuracy of information produced by your system**
+- Customers depend on your data accuracy
+- Less Common: Primarily in financial/payment industries
+
+### Detailed Breakdown
+
+#### Key Distinction
+- **CIA Integrity**: Prevents unauthorized deletion or modification
+- **Processing Integrity**: Ensures system-produced data is complete and accurate
+
+#### Typical Use Cases
+- Payroll Processing Systems: Ensure salary calculations are accurate
+- Payment Processors: Ensure transaction processing accuracy
+- HR Tools: Ensure HR data accuracy
+- Financial Software: Ensure financial report accuracy
+
+#### Implementation Characteristics
+- 5 criteria
+- Controls are often very specific and unique to the application
+- Cannot use generic control sets
+- Requires customization
+
+### Action Items
+- Evaluate if your system produces data customers depend on for accuracy
+- Document accuracy commitments in customer contracts
+- Only include if you commit to providing complete and accurate information
+
+
+## 【Chapter 11】Privacy TSC
+
+### Core Information
+- Privacy ≠ Security (often confused in industry)
+- Privacy has narrow scope; only include if relevant
+- **Don't include just because it's a fashionable term**
+- Adds significant effort and cost
+
+### Detailed Breakdown
+
+#### Key Question
+- Are you a **Data Controller** (directly interact with data subjects) or **Data Processor** (process data on behalf of others)?
+
+#### When to Include Privacy TSC
+- Data Controllers: Directly interact with individuals; handle PII (Personally Identifiable Information)
+- Have genuine privacy commitments to customers
+
+#### When Privacy TSC is NOT Needed
+- Data Processors: Only process PII on behalf of others without direct data subject interaction
+- Confidentiality TSC should suffice for report readers/customers
+
+#### Implementation Complexity
+- 8 criteria (second largest after Security's 9)
+- Significant complexity increase in reporting and testing
+- Many "not applicable" criteria often result in report redundancy
+
+#### Common Mistakes
+- Companies mistakenly include Privacy in scope
+- Result: Pay auditors to repeatedly mark "This criterion is not applicable"
+- Additional work and cost provides no business value
+
+### Key Terms and Definitions
+- **Data Controller**: Organization that determines the purposes and means of processing personal data
+- **Data Processor**: Organization that processes personal data on behalf of the data controller
+- **PII (Personally Identifiable Information)**: Any information that can identify an individual
+
+### Action Items
+- Determine if you are a data controller or processor
+- Review privacy commitments in customer contracts
+- Only include if you interact directly with data subjects
+- Evaluate if additional complexity is worth the effort
+
+
+## 【Chapter 12】Next Steps
+
+### Further Learning Resources
+- SANS Institute SOC 2 Blog
+- ByteCheck Resource Library (ByteCheck.io)
+- LinkedIn: @Ajay Yond or Twitter: @aj_yond
+
+### Key Takeaways
+- SOC 2 is third-party proof that security controls are in place
+- Choose the right TSCs based on customer commitments
+- Type 2 is the end goal, but Type 1 is a necessary stepping stone
+- Understanding the 5 report sections enables proper compliance assessment
+- Flexibility is SOC 2's greatest strength
+
+### Action Items
+- Review your customer contracts for security commitments
+- Identify which TSCs align with your commitments
+- Plan your SOC 2 journey starting with Type 1
+- Engage an auditor to discuss your specific situation
+- Build internal security maturity before the audit
+
+---
+
+**End of Summary**
+
+*Generated with Course Transcript Summarizer skill*
+*Format: Markdown | Language: English*