Salesforce Security Contacts Moved: Audit Every Org Before the Next Incident

3. Full Article

Salesforce has changed where many customers maintain the people who receive security-incident communications. For production orgs with Sales Cloud, Service Cloud, or an Industries Cloud, Security Contacts now sit on the Org Responsibilities page in Setup rather than Company Information.

The timing makes this worth checking now. Salesforce said security-contact administration could be unavailable from October 1 through October 10, 2026, while it migrated data into the new location. That migration window has ended.

Salesforce also said existing Security Contact information would continue to receive incident notifications during the transition and that data from Company Information would migrate automatically. So this is not evidence that a notification was lost. It is a clean operational trigger: verify that the migrated record is correct, active, monitored, and connected to an incident-response process in every relevant org.

For a healthcare provider, insurer, or nonprofit foundation, that last phrase matters. A Salesforce estate can span a patient-service org, a member-service org, a fundraising org, Data Cloud, MuleSoft, Marketing Cloud, Slack, Tableau, and several partners. Those products do not all use the same administration path.

What changed in October 2026?

Salesforce's Winter '27 documentation introduces Org Responsibilities, a Setup page that can hold three types of accountability information:

• Security Contact: the person or team Salesforce notifies about a security incident.
• Primary Admin Contact: the go-to person or people for product and account communications.
• Partner of Record: the service provider involved in strategy, implementation, or maintenance, when applicable.

Org Responsibilities is available in production orgs with Sales Cloud, Service Cloud, or Industries Cloud across listed Lightning Experience editions. It is not available in sandboxes or Government Cloud. A user needs the Customize Application permission to manage it.

The record includes a name, email address, phone number, last-updated value, and status. Salesforce says events such as a bounced email or user deactivation can invalidate a contact's status. That makes the page more than a new address for an old field: it gives administrators a visible signal that contact data may no longer be usable.

One Salesforce estate can have three administration paths

The most important implementation detail is that Org Responsibilities is not the universal home for every Salesforce product.

This split creates a predictable failure mode. A team checks one production org, sees a valid contact, and assumes the estate is covered. That conclusion may miss a second core org, a separate account hierarchy, a Data Cloud tenant, MuleSoft, Marketing Cloud, or Tableau.

The right control is an estate-level register, not a screenshot from one Setup page.

Do not confuse four different roles

Organizations should separate four related but different concepts.

Security Contact identifies who Salesforce should notify about security incidents. This should reach a team prepared to assess and distribute sensitive information.

Primary Admin Contact covers product and account communications. It may be the same person in a small organization, but the role and escalation expectation are different.

Designated Contact is part of the Salesforce support-access model. For several non-core products, the Primary Designated Contact has the administrative authority to edit Customer Security Contacts in the Help portal.

Trust notifications are subscriptions to operational updates such as service incidents, maintenance, or status changes. Salesforce documents separate controls for selecting instances, products, event types, and delivery channels.

A Trust subscription is useful, but it should not be treated as proof that the organization's formal Security Contact is correct. Audit both routes and document what each one is expected to deliver.

A six-step security-contact audit

1. Build the scope before editing records

List every production Salesforce org and every separately administered product or tenant. Include the org ID or tenant identifier, business purpose, region, Salesforce account relationship, internal platform owner, security owner, and support tier.

Do not limit the register to the org that appears on the CIO's dashboard. Include acquisition orgs, legacy service environments, foundation or affiliate orgs, partner-managed instances, and products operated by teams outside the central Salesforce function.

2. Verify the migrated record in every core org

In each production Sales Cloud, Service Cloud, or Industries Cloud org, open Setup and find Org Responsibilities. Confirm:

• a Security Contact exists;
• the status is active;
• the email resolves to a monitored mailbox or distribution list;
• the phone number reaches a specific person or on-call path;
• the named team has authority to receive sensitive security communications;
• the Primary Admin Contact is also current; and
• the last-updated date is consistent with the organization's review policy.

The page is not available in sandboxes, so perform the check in production with appropriately controlled administrative access.

3. Reconcile the non-core paths

For Data Cloud, MuleSoft, Marketing Cloud, Slack, Commerce, Heroku, and the other products identified by Salesforce, confirm the Customer Security Contacts in the Salesforce Help portal. Verify who is the Primary Designated Contact and whether that person can maintain the list.

Review Tableau separately in the Tableau Customer Portal. Where products sit under different accounts or contracts, confirm the tenant-to-account mapping rather than assuming one contact list covers everything.

Salesforce says contacts added for an account receive security-event notifications for all tenants listed under that account. That is useful only when the account-to-tenant inventory is accurate.

4. Use resilient contact details

Salesforce recommends a distribution list with at least two security contacts, monitored membership, reviews at least every six months and after reorganizations, and a direct phone number rather than a general support line.

Translate that guidance into an internal standard:

• use a role-based corporate address owned by security or incident response;
• keep at least two trained recipients behind it;
• exclude departed staff automatically through identity lifecycle controls where possible;
• prevent external forwarding unless explicitly approved;
• monitor delivery failures and mailbox capacity; and
• maintain a reachable on-call number with documented hours and fallback coverage.

Salesforce states that private consumer email addresses such as Gmail or Yahoo addresses cannot be used for this purpose.

5. Connect the contact to a real response process

A correct email address is not an incident-response capability. Define what happens when a Salesforce security message arrives:

1. Who validates the message and opens the internal incident?
2. Which Salesforce, security, privacy, legal, service, and business owners are paged?
3. How is the affected org, tenant, product, data set, or integration identified?
4. Where are decisions, evidence, containment actions, and vendor communications recorded?
5. Who can authorize changes that might interrupt patient, member, policyholder, donor, or grantee services?
6. When and how are executives, regulators, customers, or partners considered for notification by qualified decision-makers?

Do not send a false incident message to test the process. Instead, test the internal distribution list, phone route, ticket creation, on-call escalation, and tabletop response using clearly labeled exercise traffic.

6. Preserve evidence and review on triggers

Record the reviewer, date, source system, result, exceptions, and remediation owner for every org and product. Set a six-month review at minimum, matching Salesforce's recommendation, and add event-driven reviews after:

• mergers, acquisitions, divestitures, or account restructuring;
• changes to the CISO, Salesforce owner, support lead, or managed-service provider;
• new orgs, clouds, or production tenants;
• changes in support tier or Primary Designated Contact;
• bounced mail, inactive contact status, or failed routing tests; and
• material incident-response or on-call process changes.

What this means by industry

Healthcare organizations should connect the route to security, privacy, clinical operations, and patient-service continuity. A technically correct containment step can still create operational risk if it disables appointment, care-management, or contact-center workflows without coordinated review.

Health and general insurers should map contacts to claims, policy, billing, producer, portal, and first-notice-of-loss owners. Multi-org and acquisition-heavy estates deserve particular attention because account and product ownership can diverge over time.

Nonprofit foundations should avoid making one administrator or an external consultant the only reachable person. Document internal executive ownership and include grantmaking, fundraising, finance, and grantee-service continuity in the escalation model where relevant.

These are operational considerations, not legal, privacy, security, or compliance assurances. Qualified specialists should determine the organization's obligations and incident decisions.

Turn the new page into a durable ownership control

Org Responsibilities makes accountability more visible in core Salesforce orgs. Its value depends on the system around it: a complete estate inventory, resilient contact routes, clear administrative authority, an exercised response process, and evidence that stays current through organizational change.

The immediate goal is modest but important: prove that Salesforce can reach the right team for every production org and product, and that the team knows what to do next.

Yuniq provides Salesforce consulting and managed support, including implementation, ongoing administration, monitoring, smoke testing, and health checks. Yuniq can help inventory Salesforce org and product ownership, reconcile contact administration across channels, remediate stale assignments, and turn the result into a repeatable governance and incident-readiness cadence.

Talk to Yuniq about a focused Salesforce ownership and operational-readiness assessment: https://yuniq.co/salesforce

---