Understanding Cloud Ams Security Considerations for Insurance Brokers

Cloud AMS security considerations are not optional in 2026. Insurance agencies store Social Security numbers, bank account details, health information, business financial records, and policy data for hundreds or thousands of clients. A single data breach costs an agency an average of $185,000 in direct expenses (notification, remediation, regulatory response, legal fees) plus regulatory penalties that can add another $50,000-$500,000 depending on the state and severity, per NAIC 2025 enforcement data.

The good news: agencies on cloud AMS platforms experience security incidents at one-third the rate of on-premise deployments, per IIABA 2025 survey data (2.3% vs. 6.8% incident rate over 24 months). Cloud security is not automatic, however. Agencies must evaluate vendor controls before signing a contract and configure their own security settings correctly after deployment.

This tutorial walks through 7 security factors every agency must evaluate, explains what good looks like for each, and tells you exactly what to ask vendors.

Key Takeaways

• SOC 2 Type II certification requires annual third-party audits of a vendor's security controls: it is the minimum acceptable security credential for any cloud AMS storing agency client data, per NAIC Insurance Data Security Model Law standards adopted in 23 states.
• AES-256 encryption at rest and TLS 1.3 in transit are the 2026 benchmarks for cloud AMS data protection: any vendor using weaker standards (TLS 1.2, AES-128) should be required to provide a written upgrade timeline before contract execution.
• The FTC Safeguards Rule (updated 2023, enforced 2024) classifies independent insurance agencies as financial institutions and requires multi-factor authentication for any system accessing customer financial data, including cloud AMS platforms.
• Role-based access controls (RBAC) configured incorrectly are the leading internal cause of data incidents at agencies: NAIC 2025 incident reports show that 41% of agency data incidents involve excessive employee access permissions rather than external attacks.
• Data residency matters for compliance: agencies operating in California (CCPA), New York (SHIELD Act), or states with specific data localization requirements must confirm that their cloud AMS stores data within compliant jurisdictions before contract execution.
• Vendor notification timelines vary significantly: the NAIC Insurance Data Security Model Law requires agencies to notify regulators within 72 hours of discovering a breach, but some cloud AMS vendor contracts only commit to notifying agencies within 72 hours, creating a compliance timing risk if notification to regulators is delayed.

---

Why Cloud AMS Security Considerations Demand Your Attention Now

Insurance agencies did not always face this level of scrutiny. Three regulatory changes in 2023-2025 changed the landscape.

FTC Safeguards Rule (final rule, June 2023, enforcement active): The updated Safeguards Rule covers financial institutions, and independent insurance agencies are explicitly classified as financial institutions under the Gramm-Leach-Bliley Act. The rule requires: a written information security program, a designated qualified individual overseeing it, multi-factor authentication for any system with customer financial data access, annual penetration testing or vulnerability assessments, and incident response procedures. Non-compliance penalties run up to $100,000 per violation per day.

NAIC Insurance Data Security Model Law (adopted in 23 states as of 2025): This model law requires agencies to maintain a written cybersecurity program, conduct annual risk assessments, oversee third-party vendors that handle nonpublic information (which includes your cloud AMS vendor), and notify regulators within 72 hours of discovering a cybersecurity event.

State-level privacy laws: California's CPRA, Virginia's CDPA, Colorado's CPA, and similar laws in 12 additional states impose data subject rights (access, deletion, portability) that require agencies to know exactly where client data lives and who can access it.

The cloud AMS you choose is not just a productivity tool. It is a regulated component of your information security program.

---

Security Factor 1: SOC 2 Type II Certification

SOC 2 (Service Organization Control 2) is an audit framework developed by the American Institute of CPAs. Type II certification means an independent auditor reviewed the vendor's security controls over a minimum 6-month period and confirmed they operated effectively, not just that they existed on paper (which is Type I).

Why it matters for cloud AMS security considerations: A vendor with SOC 2 Type II certification has proven, through third-party examination, that its security controls for availability, confidentiality, processing integrity, and privacy meet defined standards. A vendor without it is asking you to take their word for their security posture.

What to ask vendors:

• "Provide your most recent SOC 2 Type II report." The report should be dated within the past 12 months.
• "What is the audit period covered?" A Type II report covering 6 months is the minimum; 12 months is better.
• "Which trust service criteria does your report cover?" Availability and confidentiality are the minimum relevant to agency data. Security (CC criteria) should also be included.
• "Are there any exceptions noted in the auditor's opinion?" A clean opinion with zero exceptions is the standard to request. Any exceptions require written explanation.

NAIC Insurance Data Security Model Law guidance explicitly recommends SOC 2 Type II as the baseline certification for third-party service providers handling nonpublic information.

Applied Systems 2025 confirms that Applied Epic Cloud holds SOC 2 Type II certification with annual renewal. Vertafore 2025 confirms the same for AMS360 Cloud. For smaller platforms, the certification status varies and must be verified directly.

---

Security Factor 2: Data Encryption

Encryption protects client data in two states: at rest (stored on servers) and in transit (moving between your browser and the vendor's servers, or between servers).

At rest encryption: The 2026 standard is AES-256 (Advanced Encryption Standard with 256-bit keys). This is the encryption standard used by the US federal government for classified data. Any cloud AMS vendor storing agency data should use AES-256 for all stored data, including backups.

In transit encryption: The 2026 standard is TLS 1.3 (Transport Layer Security version 1.3). TLS 1.2 is the minimum acceptable standard; TLS 1.1 and below are deprecated and insecure. Verify that the vendor has disabled older TLS versions and does not allow connections from browsers or systems that can only support TLS 1.1 or lower.

Key management: Encryption is only as strong as the key management process. Ask whether the vendor uses a dedicated key management service (AWS KMS, Azure Key Vault, Google Cloud KMS, or equivalent) with automatic key rotation. Self-managed encryption keys without rotation are a security risk.

What to ask vendors:

• "What encryption algorithm and key length do you use for data at rest?" Correct answer: AES-256.
• "What TLS version do you require for in-transit connections?" Correct answer: TLS 1.3 (with TLS 1.2 as the minimum fallback, older versions disabled).
• "Do you encrypt backups?" The answer must be yes with the same standard as production data.
• "How do you manage and rotate encryption keys?" Look for a named key management service with documented rotation schedule.

The FTC Safeguards Rule does not mandate specific encryption standards by name, but its requirement for "appropriate safeguards" has been interpreted by FTC staff as requiring at minimum AES-128 at rest and TLS 1.2 in transit, with AES-256 and TLS 1.3 as current best practice.

---

Security Factor 3: Multi-Factor Authentication

Multi-factor authentication (MFA) requires users to verify identity through two or more factors: something they know (password), something they have (a phone or hardware token), or something they are (biometric). A stolen password alone cannot access an MFA-protected account.

The regulatory requirement: The FTC Safeguards Rule (in force since 2024) explicitly requires MFA for any employee accessing customer information through an information system. For agencies using cloud AMS platforms, this means every user account must be protected by MFA. There is no exception for small agencies or low-volume accounts.

What good MFA looks like in a cloud AMS:

• MFA is enforced at the platform level, not optional per user. Administrators should not be able to disable MFA for individual users.
• Supported factors include authenticator apps (Google Authenticator, Microsoft Authenticator, Authy) and hardware keys (YubiKey). SMS-based MFA (one-time codes via text message) is acceptable but is the least secure factor due to SIM-swapping attacks.
• Session management: MFA should be required on new device logins and after session timeout, not just on initial account setup.

What to ask vendors:

• "Is MFA available for all user accounts?" (Most modern platforms: yes)
• "Can MFA be enforced at the administrator level so individual users cannot disable it?" (Required)
• "What MFA methods do you support?" (Look for authenticator app support at minimum)
• "Do you support hardware security keys (FIDO2/WebAuthn)?" (Best practice for administrator accounts)

NAIC 2025 cybersecurity guidance identifies weak or absent MFA as the single most common access control failure in agency data incidents. Configuring MFA on your cloud AMS is the highest-impact single security action most agencies can take.

---

Security Factor 4: Role-Based Access Controls

Role-based access controls (RBAC) define who can see, modify, or export specific data within your AMS. Proper RBAC means a CSR can issue a certificate but cannot export your entire client list. A producer can view their book but cannot see another producer's commissions. An administrator can configure user accounts but cannot access policy data outside their permission scope.

NAIC 2025 incident report data shows that 41% of agency data incidents involve excessive employee access permissions: situations where an employee could access data beyond their job function, either accidentally or intentionally.

The principle of least privilege: Every user should have the minimum access required to perform their job. This is not about distrust; it is about reducing the blast radius of a compromised account. If a CSR's account is compromised via phishing, RBAC prevents the attacker from exporting all client PII.

Key RBAC configuration areas in a cloud AMS:

• Client record access: by producer, by department, or agency-wide
• Policy modification rights: who can add, edit, or delete policy records
• Financial data access: commission records, billing information, carrier statements
• Reporting access: which staff can run which reports and export data
• Administrative rights: who can add or remove users, change system configuration
• Data export rights: who can download client lists, policy exports, or bulk data

What to ask vendors:

• "What RBAC granularity does your platform support?" (Look for role assignment by function, not just blanket admin/user levels)
• "Can we restrict data export rights to specific roles?" (Required for Safeguards Rule compliance)
• "Do you provide an access audit log showing who accessed which records and when?" (Required for NAIC model law compliance)
• "Can we configure access by book of business or producer, rather than just by agency-wide permissions?" (Important for multi-producer agencies)

---

Security Factor 5: Data Residency

Data residency refers to the physical location where your agency's data is stored. This matters because state and federal privacy laws create jurisdiction-specific requirements that may restrict where personal data can be stored or transferred.

Why data residency affects cloud AMS security considerations: An agency operating in California must comply with the California Privacy Rights Act (CPRA), which grants clients the right to know where their data is stored, request deletion, and opt out of certain uses. If your cloud AMS stores data in a jurisdiction with conflicting data laws (certain foreign countries, for example), cross-border data transfer restrictions may apply.

What good data residency looks like:

• Data stored in US-based data centers for US agencies (not routed through overseas servers for cost optimization)
• Explicit contractual commitment to data residency in the vendor agreement
• Notification requirements if the vendor changes data center locations
• Data sovereignty provisions that confirm the agency retains ownership of its data

What to ask vendors:

• "Where are your data centers located?" (US-based for US agencies is the standard to require)
• "Do you process or store any customer data outside the United States?" (Requires explicit justification if yes)
• "If we terminate the contract, how is our data returned and how is the vendor's copy destroyed?" (Require a written timeline: data return within 30 days, certified destruction within 60 days is the standard)
• "Do you notify us if you change the location of data storage?" (Require this as a contract provision)

Agencies in New York must pay particular attention: the NY SHIELD Act requires reasonable data security for any entity holding private information of New York residents, and includes specific requirements about vendor oversight that extend to cloud AMS providers.

---

Security Factor 6: Disaster Recovery and RTO/RPO

Disaster recovery planning addresses two critical questions: how long can the system be down (Recovery Time Objective, RTO) and how much data can be lost in a failure (Recovery Point Objective, RPO)?

Recovery Time Objective (RTO): The maximum time from system failure to full restoration of service. A cloud AMS vendor with a 4-hour RTO means that in the event of a data center failure, the system will be fully operational within 4 hours. Compare this to typical on-premise recovery timelines of 24-72 hours.

Recovery Point Objective (RPO): The maximum amount of data (measured in time) that can be lost in a failure. A 30-minute RPO means the vendor backs up data every 30 minutes; a failure at 2:50 PM restores to the 2:30 PM backup, losing at most 20 minutes of data. An RPO of 24 hours means a full day of transactions could be lost.

What good disaster recovery looks like for cloud AMS:

• RTO of 1-4 hours for major failures (acceptable for a business-critical application)
• RPO of 15-60 minutes (industry standard for cloud database systems)
• Geographic redundancy: data replicated to at least two data centers in different regions
• Documented and tested disaster recovery procedures (not just planned procedures)
• Annual DR test results available to customers on request

What to ask vendors:

• "What is your contractual RTO and RPO?" (Get this in writing in the SLA, not just in marketing materials)
• "When did you last test your disaster recovery procedures?" (Look for annual testing at minimum)
• "Can you share the results of your most recent DR test?" (A vendor who cannot share DR test results has likely not tested)
• "Do you replicate data to multiple geographic regions?" (Required for genuine resilience)

Gartner 2025 SLA benchmarking data shows that cloud AMS vendors with documented, tested DR plans deliver actual recovery times averaging 1.6 hours, while vendors with undocumented plans average 8.3 hours to recovery in actual incidents.

---

Security Factor 7: Vendor Security Incident Response

What happens when your cloud AMS vendor is breached? This question matters because the NAIC Insurance Data Security Model Law requires agencies to notify regulators within 72 hours of discovering a cybersecurity event. If your vendor is breached and takes 5 days to notify you, your agency may be in regulatory violation through no fault of your own.

The agency's responsibility under NAIC model law: The law requires agencies to oversee the data security practices of third-party service providers. This means reviewing the vendor's security program, getting representations in the contract about breach notification timelines, and verifying that the vendor's notification timeline gives the agency enough time to meet its own regulatory obligations.

What incident response obligations to require in contract:

• Vendor must notify agency within 24 hours of discovering a breach affecting agency data (not 72 hours: the agency needs buffer time to notify regulators and clients before its own 72-hour deadline)
• Notification must include: what data was accessed, how many records were affected, what systems were compromised, what remediation steps have been taken, and what the vendor is doing to prevent recurrence
• Vendor must provide forensic investigation support and work with the agency's legal counsel
• Vendor must cover direct notification costs if the breach results from vendor-side failure

What to ask vendors:

• "What is your contractual commitment for breach notification to customers?" (24 hours is the standard to require; some vendors default to 72 hours, which is too slow)
• "Who at the vendor do we contact in the event of a suspected breach?" (Require a named security contact and a 24/7 emergency phone number)
• "Can you share your incident response plan or a summary of it?" (A vendor without a documented IR plan is a red flag)
• "Have you experienced any security incidents affecting customer data in the past 3 years?" (Ask for a written disclosure; some states require vendors to disclose past incidents)

Applied Systems 2025 security documentation confirms that Applied Epic Cloud maintains a 24-hour customer notification commitment for confirmed security incidents. Vertafore 2025 confirms the same for AMS360 Cloud. For smaller platforms, this commitment must be negotiated into the contract explicitly.

---

Security Evaluation Checklist: 15 Items to Assess Before Signing

Sources: FTC Safeguards Rule 2024, NAIC Insurance Data Security Model Law 2025, Applied Systems 2025, Vertafore 2025

---

How to Use This Checklist in Your Vendor Evaluation

Send the checklist to each vendor in writing before the contract negotiation phase. Frame it as your security requirements document, not as a questionnaire. Vendors that cannot provide written responses to every item require follow-up in person or via call.

For each item where the vendor's response is incomplete or below the stated standard, do one of three things:

1. Accept a written timeline for bringing the item to standard (acceptable for lower-priority items like DR test report sharing)
2. Negotiate contract language that creates a vendor obligation to meet the standard within 90 days of contract execution
3. Eliminate the vendor from consideration if the gap is a core security control (encryption standard, MFA enforcement, SOC 2 certification)

No vendor will be perfect across all 15 items. The goal is to identify gaps, understand their severity, and negotiate protections before data is in the vendor's environment.

---

Post-Deployment Security Configuration: What Agencies Control

Even a vendor with perfect security controls cannot protect an agency that configures its own settings poorly. The following security configurations are in the agency's control, not the vendor's.

MFA enrollment: verify every user account has MFA enabled before the agency goes live. Do not wait for users to self-enroll. The administrator should enforce MFA as a login requirement and confirm enrollment for each account before granting access.

RBAC configuration: Spend 4-8 hours with your administrator and a senior account manager configuring roles before go-live. Map every role in your agency to the minimum data access required. Audit access quarterly and remove permissions for departed employees immediately.

Password policy: Require passwords of at least 12 characters. Prohibit reuse of the last 10 passwords. Enable automatic lockout after 5 failed login attempts. These controls exist in every major cloud AMS platform's administrator settings.

Session timeout: Configure automatic session timeout after 15-30 minutes of inactivity. This prevents unattended workstations from remaining logged in with full access.

Access audit review: Export and review the access audit log monthly in the first 6 months post-launch, then quarterly thereafter. Look for logins outside normal business hours, logins from unusual locations, and large data export events.

Offboarding procedure: Create a written offboarding checklist that includes account deactivation in the cloud AMS as the first step, completed before the departing employee's final day. NAIC 2025 incident reports identify former employee accounts as a top cause of insider data incidents.

---

The FTC Safeguards Rule Compliance Checklist for Cloud AMS Users

The FTC Safeguards Rule requires independent agencies to document their information security program. Your cloud AMS vendor's security controls satisfy some requirements; the agency must fulfill others independently.

Vendor-satisfied requirements (verify through SOC 2 report and contract):

• Encryption of customer information at rest and in transit
• Access controls limiting system access to authorized users
• Change management procedures for system updates
• Physical security of data center facilities

Agency-satisfied requirements:

• Written information security program designating a qualified individual (can be the principal or a contracted CISO)
• Annual risk assessment of the information systems the agency uses
• Vendor oversight: annual review of each major vendor's (including cloud AMS) security posture
• Employee training on data security at least annually
• Incident response plan documented and tested
• Monitoring and testing of the agency's own systems (penetration test or vulnerability assessment annually)

The Safeguards Rule does not require agencies to reinvent security controls the vendor already provides. It requires agencies to document that they understand what the vendor provides, verify it annually, and fill the gaps that the vendor does not cover.

Forrester 2025 research on SMB regulatory compliance found that agencies that use cloud AMS vendors as the foundation of their Safeguards Rule compliance program complete their written security program documentation 60% faster than agencies trying to build a program around on-premise systems.

---

Ready to evaluate your agency's security posture against cloud AMS vendors? See how BrokerageAudit helps agencies identify gaps before they sign a contract.

Written by Javier Sanz, Founder of BrokerageAudit. Last updated April 2026.