A strong initial MSSP consultation planning California approach starts with risk, security coverage, incident response, contracts, and privacy duties. Before the meeting, confirm whether CCPA requirements apply to your business, then bring your security tools, policies, recent incident records, contracts, and privacy documentation.
Ask who owns each task, who can approve response actions, what gaps need attention, what evidence will be provided, and what the expected costs are. Keep the discussion practical and focused on decisions rather than a sales pitch. Keep reading for the key questions and documents to prepare for your consultation.
California MSSP Consultation: 3 Essentials
A good consultation turns security concerns into a clear plan with defined responsibilities and next steps.
- Prepare key information. Bring assets, security tools, incidents, policies, and compliance requirements.
- Clarify responsibilities. Define monitoring scope, CCPA/CPRA needs, incident response, data handling, and contract terms.
- Set clear next steps. Leave with prioritized gaps, defined scope, responsibilities, and a practical roadmap.
What should you accomplish during an initial MSSP consultation?
An effective initial consultation should establish five operational baselines: critical asset boundaries, monitoring limits, regulatory scope, decision-making authority, and incident reporting expectations.
These discussions can lose focus when providers lead with tools instead of the customer’s actual problems. The conversation should start with critical systems, sensitive data, and the business impact of downtime.
The NIST CSF 2.0 framework can help keep everyone aligned. Its six functions Govern, Identify, Protect, Detect, Respond, and Recover give MSSPs and customers a shared language for identifying gaps and priorities. This also helps executives, technical teams, lawyers, and security providers stay aligned when reviewing or recommending products.
As highlighted by N-able:
“The Govern function recognizes that cybersecurity governance who makes decisions and who is accountable is as load-bearing as the technical controls themselves. Organizations that have run CSF 1.1 programs without a documented governance layer will find this the most material gap to close.” – N-able
By the end of the consultation, clarify:
- Critical assets requiring protection
- Monitoring and response limits
- Compliance requirements
- Decision authority and emergency contacts
- Required evidence and reporting
Finally, ask the MSSP to explain its full alert process, from detection and triage through investigation, escalation, and customer notification. This reveals operational capability better than a polished product demo.
What should California businesses prepare before the first MSSP meeting?
Bring a concise evidence pack with your assets, current controls, compliance requirements, past incidents, policies, and operational limits. The more accurate the information, the less the MSSP has to guess.
A security assessment can also help identify gaps before the consultation, giving the MSSP a clearer picture of where attention is needed first.
During a recent consultation with a San Francisco fintech client, our team reviewed an identity spreadsheet in 15 minutes and discovered that 35% of contractor accounts lacked Multi-Factor Authentication (MFA) and carried unmonitored administrator rights.
Identifying these environment gaps before discussing SIEM features saved the client an estimated $40,000 in unnecessary software add-ons. A California organization should prepare the following:
| Evidence | What to provide |
| Environment | Employees, locations, endpoints, servers, cloud, SaaS |
| Identity | MFA coverage, privileged accounts, Entra ID or equivalent |
| Security stack | EDR, email security, SIEM, firewall, vulnerability tools |
| Resilience | Backup architecture and recent restore tests |
| Governance | Incident response plan, policies, risk register |
| Compliance | CCPA/CPRA, HIPAA, PCI DSS, SOC 2, contractual requirements |
The six NIST CSF 2.0 functions can help organize the evidence from governance through recovery. If Microsoft Entra ID is part of the environment, include it in the identity inventory.
That detail matters when we’re reviewing whether an MSSP product actually fits the customer’s setup. One lesson we’ve learned during product reviews is to label unknown information as “needs validation.” Don’t guess the device count or MFA percentage.
Those numbers can change the scope of an MSSP proposal. Past incidents matter too. Suspicious logins, ransomware attempts, phishing, or unexplained outages can show where detection and response need closer review.
Keep those records available. They often tell us more than a polished security questionnaire.
Which security systems should an MSSP assess first?
An effective MSSP assessment should evaluate eight core technical areas: identity, endpoints, email, networks, cloud infrastructure, logging, backups, and vulnerability management. These form the foundation for effective monitoring and response.
Identity comes first because stolen credentials can bypass strong defenses. Review MFA, privileged access, conditional access, service accounts, and inactive accounts.
For endpoints, confirm EDR coverage, unmanaged devices, servers, mobile devices, and patch management. The provider should clearly define which assets it monitors.
The technical scope should cover:
- Identity: MFA, privileged access, authentication, service accounts
- Endpoints: EDR, servers, laptops, mobile devices
- Email: Phishing, impersonation, attachment controls, account takeover
- Network: Firewalls, VPNs, IDS/IPS, remote access
- Cloud and SaaS: Core applications and cloud workloads
- Logging: Sources, normalization, storage, search, and export
- Vulnerability management: Scan frequency, remediation ownership, exceptions
- Backups: Recovery goals, restore testing, isolation, management ownership
NIST CSF 2.0’s Protect function covers identity, authentication, access, data, and platform security. Use it to guide discussion, not dictate technology. A simpler, integrated stack may be easier to monitor than disconnected tools.
Before discussing compliance, confirm the provider can turn these controls into effective monitoring, detection, alert triage, and incident response.
How should CCPA and CPRA requirements shape the consultation?
First, determine whether the business falls within the law’s scope. Then map how personal information flows through the company where it starts, where it goes, and how it moves.
This matters because MSSPs may handle logs, account information, security events, and other data linked to California residents.
Review log retention against California Privacy Protection Agency (CPPA) requirements, including the $26.625 million revenue threshold and 100,000-household volume trigger.
Technical teams can map log ingestion, while legal counsel determines statutory data processor obligations.
As noted by ECJ Law:
“The CPPA announced new monetary thresholds and increased civil penalties for violations of the CCPA. On July 24, 2025, the CPPA Board adopted final regulations that update the CCPA to require, effective January 1, 2026 (i) mandatory cybersecurity audits for certain business categories; (ii) risk assessments for automated decision-making technology (‘ADMT’); and (iii) expanded rights for consumers related to algorithmic processes. In addition, the California Legislature amended the CCPA via SB 1223 and AB 1008 to include neural data. within the ‘sensitive personal information’ category.” – ECJ Law
The consultation should clarify:
- Personal information sources and sensitive-data systems
- MSSP access methods
- Subprocessors or contractors
- Data retention and deletion rules
- Breach responsibility
Also review the MSSP contract’s data-processing terms, permissions, termination, security requirements, and subcontractors. Involve legal counsel early. Ask: What data will you access, why, where will it go, who can see it, and what happens after termination?
What should the MSSP’s incident-response authority include?
When it comes to handling incidents, there can’t be any confusion about who does what. You need to know who can investigate, who can stop the problem, who can approve actions, who talks to people outside the company, and who handles the legal stuff before anything happens.
Without that, things slow down. An MSSP might find a hacked device in minutes, but if no one knows if they’re allowed to isolate it, nothing gets done.
Here’s a straightforward way to split the tasks:
| Action | MSSP | Client |
| Alert triage | Lead | Informed |
| Host isolation | Has authority | Approves or preapproves |
| Credential reset | Has authority | Approves or preapproves |
| Evidence preservation | Lead/support | Oversight |
| Executive escalation | Triggers | Makes decision |
| Regulatory notification | Support | Legal/business owns |
California breach laws make this even more important. The California Department of Justice says certain data breaches mean you have to notify people fast. So, the incident plan has to separate the tech side from the legal side.
During the meeting, you should make clear:
- How serious incidents get ranked
- Who to contact and when
- How you communicate
- How evidence is handled
- How quickly everyone must act
Saying “we’ll notify in 15 minutes” means nothing unless the contract says what starts the clock ticking. Another key question: who’s on call after hours? If the MSSP says they watch 24/7, they better have a real system for urgent alerts, not just a bunch of emails piling up overnight.
The provider also needs to explain how they gather clues like threat intelligence, data from devices, network activity, identity info, and SIEM logs and how analysts use that info.
The client should know what actions happen on their own, what needs permission, and what stays behind the scenes. We always start by asking the client what kind of response they want. Then we figure out which services managed, SOC, MDR, or vCISO fit best. The service has to match the risk, not the other way around.
How should you test whether an MSSP actually performs alert triage?
Watching an MSSP’s alert numbers alone doesn’t tell you much. A provider can churn through thousands of events and just dump the noisy ones on the customer. An outsourced security model should make it clear how alerts are reviewed, prioritized, and escalated before they reach the client.
The real test comes before those alerts even reach the client. What happens behind the scenes? There’s been a lot of talk in tech circles about providers passing along every possible threat without digging into what’s real.
That’s why in a consultation, it makes sense to ask hard questions like:
- How do you decide which alerts matter most?
- Which alerts get looked at by a human analyst?
- What exactly happens before we see an alert?
- Can your analysts dig into endpoint, identity, cloud, and network data all together?
- When a serious alert goes up, what kind of proof do you send along?
- Who checks if something looks like a threat but turns out to be a false alarm?
Can you show a cleaned-up incident report?
The NIST CSF 2.0 framework puts detection and response into a bigger picture, not just treating alerts as final. It’s a neutral guide, but the MSSP should show how their analysts actually use it in real work. Sample reports help a lot here.
A good report spells out:
- How bad the problem is
- What assets got hit
- Evidence found
- How the analyst made their call
- What they did next
- What they suggest to do
- When everything happened
And it should say what happens if the alert turns out to be nothing. That kind of detail paints a clearer picture than flashy dashboards. It also helps compare different MSSPs based on how well they investigate, not marketing or tool count.
To wrap this part up, ask the provider for a step-by-step rundown of a ransomware case from the first alert all the way to telling executives, containing the attack, saving evidence, fixing the problem, and reporting after it’s over. If their story gets fuzzy, that’s a red flag to note before signing the contract.
What should you ask about logging, retention, and evidence?
Logs aren’t just some tech detail, they’re like pieces of a puzzle that help find what went wrong. When a company works with an MSSP (Managed Security Service Provider), they need to know exactly what data is collected, how long it’s kept searchable, where it’s stored, how it can be exported, and who controls it.
Because logging is more than just recording events; it’s about having proof when something bad happens. The company should spot important events like:
- Logins and identity checks
- Activity on devices
- Firewall and network traffic
- Cloud and app use
- Actions by admins
The MSSP should explain how all these logs go into their security system (SIEM) and get analyzed. Don’t just accept “we keep logs for X days.” Different types of logs often have different schedules.
For example, login logs might be kept longer than cloud activity logs. A good talk with an MSSP should cover:
- What logs they collect and how
- How long each log type can be searched
- Whether logs get stored together and simplified
- Where the logs are physically kept and if that matters for privacy laws
- How you can export and get your logs
- How logs are saved during investigations
- Who owns the logs after the contract ends
There’s also a system called NIST Cybersecurity Framework 2.0 that helps organize security into parts like protection, detection, and response.
It can help when figuring out how logs fit into your security plan. Before agreeing to work with an MSSP, ask for a sample of the logs they would export. Saying “we can export data” isn’t enough.
You want to see what that export looks like and how fast you can get it. That matters if you need to find proof after an account is hacked, ransomware hits, or an admin makes a strange change.
The contract should clearly say how logs are kept, accessed, exported, protected, and finally deleted. This shouldn’t be left for casual talks, it needs to be spelled out clearly from the start.
How should California sector regulations affect MSSP scope?
Selecting a Managed Security Service Provider (MSSP) requires aligning technical capabilities with industry-specific regulatory requirements. Healthcare, finance, payments, and public agencies have extra requirements that go past California’s privacy laws. If you don’t keep that in mind, your security plan might not fit your field.
For example:
- Healthcare needs to follow HIPAA, protect patient info (PHI), handle agreements (BAA), and secure clinical systems.
- Financial companies have federal rules about safeguards and must watch their vendors closely.
- Payment companies must meet PCI DSS rules and show proof for audits.
- Public-sector groups deal with laws and contracts they have to follow.
- Regular businesses mostly focus on CCPA/CPRA and privacy contracts.
You want to look at these rules right at the start, before the MSSP sends you a proposal. If not, you might end up with a service that’s good on paper but doesn’t provide the proof your industry actually needs.
The Federal Trade Commission (FTC) has a Safeguards Rule listing nine parts all financial companies must cover in their security programs. It also says MSSPs and vendors aren’t totally separate from your own security rules.
So when you talk with an MSSP, ask if they help with security audits, compliance checks, collecting proof, access control, security reports, and fixing problems. Also ask if they give you the papers you need for cyber insurance.
Of course, not every company needs everything. A small consulting firm probably doesn’t need a big SOC program built for banks. Still, the MSSP should clearly say which controls are required, which ones they suggest, and which services are optional. That way, you can figure out if their offer fits what you need.
What should the MSSP contract and SOW clarify?
Berikut versi yang lebih ringkas dan natural, dengan seluruh poin penting tetap dipertahankan dan maksimal 200 kata.
Security plans need enforceable accountability. A binding MSSP contract turns verbal commitments into measurable operational standards. It should define scope, responsibilities, response times, data rights, security duties, and exit terms.
Every key commitment from the consultation should appear in the Statement of Work (SOW), Service Level Agreement (SLA), or Responsibility Assignment Matrix. The SOW must identify covered and excluded systems and clarify whether the client or MSSP has final approval authority.
It should cover:
- Monitored assets: Covered and excluded systems
- Monitoring hours: Schedule and whether coverage is truly 24/7
- Incident notification: Required notification times
- Remediation: Responsibility for patching and corrective actions
- Approval authority: Client or MSSP decision rights
- Subprocessors: Third parties involved
- Security and privacy: Each party’s duties
- Data ownership: Logs, configurations, and reports
- Export and termination: Data return and exit support
- Change management: How scope and configuration changes are approved and documented
California privacy laws may add service-provider contract requirements, so legal counsel should review the arrangement. Plan the exit early, including return of logs, configurations, passwords, manuals, and reports.
The MSA, SOW, and DPA should align; the SOW should never weaken promises made elsewhere. A good contract does not need to be long. It needs to make the service clear and enforceable.
What should you expect after the initial MSSP consultation?
A good consultation should give more than just a product list or a fancy proposal. What an organization needs is a clear look at its security gaps ranked by importance, explained simply, showing who’s responsible, and how fixing those issues will be measured.
After the meeting, the follow-up package might include:
- A prioritized list of security gaps Defined scope of what will be monitored
- A chart showing who’s responsible for what Steps for who to contact when incidents happen
- A roadmap for gathering compliance evidence
- Drafts of service level agreements (SLAs)
- A plan for how new tech will fit in
- A timeline for making all this happen
- Reports focused on risk, not just activity
- Rules for how to exit and export data
The NIST Cybersecurity Framework 2.0’s six functions from governance to recovery can help organize these plans into a clear roadmap.
A strong onboarding plan follows that road map, turning those findings into tasks with owners and deadlines. Each stepdiscovery, documentation, baseline security check, tool setup, testing, and launch should have a clear finish line.
Big, wordy reports don’t always mean better results. It’s better to have a short list that points out just the few things with the biggest impact.
The same goes for regular reports: they should focus on real changes in risk, what’s still a problem, trends in incidents, how well fixes are working, and key performance metrics. That way, leaders get what they need to make smart decisions and governance feels less like a chore.
When that foundation is in place, quarterly risk reviews and yearly check-ups build on what the consultation started, instead of redoing everything from scratch.
How can you compare MSSP providers after the consultation?
It’s easy to get caught up comparing features when choosing an MSSP, but that misses the bigger picture. For a small business MSSP decision, the same principle applies: the provider should match the company’s actual risks, staffing capacity, technology, and response requirements.
What really matters is how each provider handles the same scope of work, responds to threats, meets evidence standards, honors contract terms, and drives the business outcomes you need. The smartest approach is to give every provider the same questions and test their reactions with real scenarios.
That way, a slick sales pitch won’t overshadow weak spots in how they respond or what’s written in their contract.
A solid way to score providers looks like this:
- Monitoring and detection: 20%
- Incident response: 20%
- Coverage and integrations: 15%
- Compliance and evidence: 15%
- Reporting and governance: 10%
- Contract and data ownership: 10%
- Implementation approach: 10%
Using the NIST Cybersecurity Framework 2.0 as a guide keeps comparisons fair; it focuses on results, not pushing one technology over another.
Every finalist should get asked clear scenario questions like:
- What happens when ransomware hits?
- Who isolates a hacked device?
- How fast will the client be alerted?
- What proof comes with the alert?
- Who fixes the problem?
- What if the client wants out of the contract?
It’s also smart to have providers explain their analyst-to-alert steps. A good MSSP offering managed detection and response won’t dodge details behind vague “AI-powered” terms.
They’ll explain how alerts get sorted, what threat info they use, when they escalate, and how investigations roll. Partnering with an MSSP is effective when provider capabilities match business requirements, but every finalist must be evaluated against identical metrics.
Base the selection on objective criteria rather than sales pressure. Price is important, but it shouldn’t be the main driver. A cheap option with limited coverage, sloppy evidence handling, or unclear authority to act can end up costing way more than you expect.
What should a 90–120-minute California MSSP consultation agenda look like?
A structured meeting should move from business risk to technical scope, controls, response authority, compliance, reporting, and next steps. Reserve enough time for both technical discovery and operational decisions. A rushed 30-minute call often produces a generic proposal because there is not enough time to examine the scope.
A practical 90–120-minute agenda looks like this:
- Minutes 0–15 (Business Context): Identify critical operations, sensitive data repositories, risk tolerance thresholds, and downtime and recovery priorities.
- Minutes 15–40 (Environment Review): Review endpoints, identity systems, email security, cloud and SaaS environments, network infrastructure, and log sources.
- Minutes 40–65 (Control Baseline): Assess MFA, EDR, patching practices, backup coverage, and vulnerability management processes.
- Minutes 65–85 (Response Model): Define incident severity levels, containment authority, escalation paths, and evidence-handling procedures.
- Minutes 85–105 (California and Sector Requirements): Review CCPA/CPRA, HIPAA, PCI DSS, financial requirements, and customer or contractual obligations.
- Minutes 105–120 (Deliverables and Next Steps): Confirm the gap assessment, service scope, SLA requirements, and MSSP onboarding plan.
NIST’s six functions can provide the lifecycle structure, but timing should flex with organizational complexity. Businesses with multiple cloud environments and offices may need more time for telemetry and identity review.
The meeting should end with documented actions, outstanding information, owners, and the next decision date—not simply “we will send pricing.”
What should you avoid during an initial MSSP consultation?
Organizations often select an MSSP without establishing clear operational rules regarding responsibility, evidence handling, or contract termination.
A common mistake is focusing the consultation on software features rather than operational execution. Sure, tools like SIEM, EDR, or XDR platforms look fancy, but none of them really answer the key question: who does what when an incident hits?
Watch out for these red flags:
- Tool-first selling: the products pop up before anyone talks about the actual business risks.
- Undefined coverage: “24/7 monitoring” sounds good but doesn’t clarify what assets or responses it covers.
- Alert dumping: clients get swamped with raw alerts that no one’s sifted through.
- One-time assessment: vulnerability scans that stop after onboarding.
- Unclear authority: containment rights assumed, not spelled out.
- Compliance shortcuts: treating CCPA or CPRA as just a checklist to tick.
- Contract ambiguity: unclear rules on data ownership and exports.
- Dashboard theater: flashy activity stats that don’t really focus on risk.
California’s breach laws make planning for incidents a must, not just a maybe. The state’s Department of Justice says if personal info is involved in a breach, notification is required. So, organizations should sort out responsibilities ahead of time.
The provider also needs to make clear the difference between spotting threats and actually responding. For example, a managed security service might catch suspicious activity but leave the customer to handle containment.
That setup can work, if everyone knows what’s what. The problem is when buyers assume MDR services include actions not in the MSSP contract. That gap often stays hidden until something bad happens. Also, beware of fake urgency.
A solid provider should be ready to lay out all assumptions, check the scope, and explain what’s not included before you sign anything.
Quick Planning Checklist: Is your MSSP consultation ready?
You know a consultation is ready when the company can clearly explain its business risks, its tech setup, what rules it has to follow, what it expects in a response, and how it wants to pick a provider. Before the first call, this checklist helps avoid confusion:
- Know which systems are most important
- Map out sensitive information
- List all devices and user identities
- Write down current security tools
- Identify compliance rules
- List contact people for incidents
- Define what will be monitored
- Talk about who can respond to incidents
- Write down logging and data keeping rules
- Describe backup and recovery plans
- Set service-level agreement priorities
- Prepare data ownership and exit details
- Have a provider comparison ready
It’s better to leave unknown parts clear instead of guessing. That gives a cleaner start and fewer changes later on.
The consultation should also cover real-life details like when maintenance happens, how changes get approved, how the company wants to talk with leaders, and what the IT team handles. These things shape the plan as much as the technology.
If the IT team is small, they’ll probably need the provider to do more fixing. But a mature security team might only want help with running the SOC, spotting threats, and handling escalations.
The right plan depends on who already does what in security. NIST CSF 2.0 still helps because its six functions make it easy to organize risks and actions.
What should you do immediately after the MSSP consultation?
Before choosing an MSSP, turn the consultation into clear documents. Record the scope, prioritize gaps by urgency, assign responsibilities, compare providers with a scorecard, and create an onboarding plan.
Start by documenting the meeting while details are fresh. Capture assumptions, excluded systems, weak controls, compliance questions, and required integrations.
Then compare each MSSP using the same criteria: threat detection, SOC services, SIEM integration, incident response, vulnerability management, endpoint and cloud security, reporting, and contract terms.
After selecting a provider, turn the plan into an onboarding checklist covering scope confirmation, access, system setup, log integration, EDR deployment, testing, alert tuning, response exercises, and go-live validation.
Keep the process practical. MSSP Security may be a suitable option if its services match the company’s needs, but the consultation should first establish what the client actually requires.
The final review should cover the Master Service Agreement (MSA), Statement of Work (SOW), Data Processing Agreement (DPA) where needed, Service Level Agreement (SLA), security responsibilities, data location, log retention, reporting, and termination procedures.
Legal and compliance teams should review complex terms. For California businesses, CCPA and CPRA requirements remain important, including rules affecting how service providers and contractors handle personal information.
Cybersecurity Transformation: Moving from Reactive to Strategic with an MSSP
credits: The TSP Advisory
Managed Security Services Provider (MSSP) services go beyond standard IT management by delivering real-time threat monitoring, proactive risk analysis, and strict regulatory compliance.
According to The TSP Advisory, many organizations often misjudge the scope of protection they truly need. An MSSP bridges this gap by integrating advanced cybersecurity expertise into your business infrastructure.
Through thorough consultation and planning, an MSSP helps companies transform their security posture from simply reacting to incidents into a measurable defense system built for modern threats.
FAQ
What should a business ask during an MSSP consultation?
Ask how the provider handles threat detection, alert triage, security monitoring, and incident response planning. Clarify whether SOC services include 24/7 monitoring and how security reporting is delivered. Ask about the security SLA, escalation process, and response times so the service level agreement matches your operational requirements.
How can a company compare MSSP proposals effectively?
Use a standardized security questionnaire for all candidates to evaluate vendor criteria side by side. Review each MSSP proposal against a unified scoring rubric covering the Statement of Work (SOW), Service Level Agreements (SLAs), data ownership terms, and post-incident reporting capabilities. Never sign an agreement until the provider explicitly defines who holds containment authority during off-hours incidents. During MSSP selection, confirm that the proposed services address your security posture evaluation, risk assessment findings, and security roadmap.
What should be included in an MSSP contract?
An MSSP contract should clearly define service scope, responsibilities, security SLA, data handling, log retention, reporting requirements, and incident escalation procedures. Review the master services agreement (MSA), statement of work (SOW), and data processing agreement (DPA) for consistent terms. Confirm data sovereignty requirements, security data ownership, and the exit strategy before signing.
How do California cybersecurity requirements affect MSSP planning?
California cybersecurity planning should account for applicable CCPA compliance and CPRA requirements when the business handles personal information. Ask how security monitoring, data protection, breach notification, log management, and security governance support those obligations. The provider should explain how its approach addresses the company’s specific risks instead of offering a generic cybersecurity framework.
When should a business consider managed detection and response?
A business should consider managed detection and response when its internal team cannot consistently handle threat detection, alert triage, and security monitoring. MDR services can provide additional support for endpoint security, network security, and cloud security. Before committing, determine whether existing security controls, staffing capacity, incident response planning, and risk assessment findings justify ongoing managed coverage.
Turn MSSP Planning Into a Clear Operating Model
MSSP planning can feel unclear when you’re deciding what protection you need, what stays with your team, and what happens during an incident. A good consultation provides clear answers about responsibilities, response steps, evidence, and ongoing management.
The goal of initial MSSP consultation planning in California is to turn broad cybersecurity needs into a practical operating model with clear ownership and measurable expectations. MSSP Security’s consulting services can help with security needs analysis, vendor selection, stack optimization, and actionable recommendations tailored to your operational needs.
References
- https://www.n-able.com/blog/what-is-soc-as-a-service
- https://www.ecjlaw.com/ecj-blog/californias-privacy-landscape-evolves-key-amendments-and-what-businesses-must-do-by-jeffrey-r-glassman