Profiles and Sharing Rules operate at the APPLICATION access layer, controlling whether a specific user is permitted to query, view, or edit a given piece of data through Salesforce's normal interface and API — if a user lacks the appropriate Object-Level Security or record-level Sharing access, they simply cannot retrieve that data through any standard Salesforce interaction, but the underlying data itself remains stored in a readable, unencrypted form within Salesforce's infrastructure. Shield Platform Encryption instead operates at the STORAGE layer, encrypting the actual field data at rest in the underlying database using encryption keys the customer organization controls, meaning even in a scenario where the application-layer access controls were somehow bypassed or compromised at an infrastructure level, the underlying data itself would remain unreadable without the encryption key. These are genuinely complementary, not competing, layers of protection — a mature security posture for genuinely sensitive data typically uses both together, application-layer access control as the primary everyday gate, and storage-layer encryption as an additional layer specifically addressing infrastructure-level risk and certain regulatory requirements.

Event Monitoring is the tool that should have been proactively enabled, since it provides significantly longer retention than standard Login History's 6-month limit, along with genuinely more detailed activity logs including Report Export events, which are specifically relevant to a data exfiltration investigation since they would show exactly who exported what volume of data and when. It matters that this needed to be enabled PROACTIVELY, before the incident occurred, because logging and monitoring tools like Event Monitoring can only capture activity that happens WHILE they are active and properly configured — there is no way to retroactively generate detailed historical logs for a period before the tool was turned on, meaning an org that only considers enabling Event Monitoring AFTER a suspected incident has already permanently lost the ability to have the kind of detailed forensic data this specific 8-month-old investigation would need. This is precisely why comprehensive security tooling like Event Monitoring is something a mature security posture enables proactively as standard practice, not reactively after a specific incident is already suspected.

Health Check specifically evaluates SETTINGS-based security configuration — items like Password Policy strength, Session Settings timeout values, and certain System Permissions being appropriately restricted on non-Admin Profiles — comparing these specific, checkable settings against Salesforce's recommended baseline values and producing a score based on how closely the org's actual configuration matches those recommendations. It does NOT evaluate the genuine architectural QUALITY or appropriateness of an org's Role Hierarchy design from Module 4 or its Sharing Rule structure from Module 5 — these are fundamentally design and business-judgment questions about whether the RIGHT people have access to the RIGHT data for the RIGHT reasons, which is a categorically different kind of evaluation than checking whether a password minimum length setting meets a recommended threshold. An org could have perfectly strong password policies and session timeouts, scoring excellently on Health Check, while simultaneously having an overly broad Sharing Rule that inappropriately exposes sensitive Opportunity data to an entire department that should never have seen it — a genuine security failure Health Check has no mechanism to detect, since sharing model design quality is simply outside what this specific automated tool evaluates.

Event Monitoring is fundamentally a REACTIVE, logging-based tool — it records detailed information about events like Report exports as they happen, but this data exists specifically to be reviewed and analyzed AFTER the fact, whether by an Admin manually investigating a specific concern or through a Dashboard tracking activity patterns over time; the export itself is never prevented or interrupted by Event Monitoring alone, it is simply logged for later visibility. A Transaction Security Policy is fundamentally PROACTIVE and REAL-TIME — it defines a condition, such as a Report export exceeding a certain row count, and when that exact condition is matched, the platform immediately takes an automated action in that moment, such as blocking the export entirely, requiring additional MFA verification before allowing it to proceed, or immediately notifying a security team, all happening as the risky action is actually occurring rather than being discovered afterward through log review. This means an organization relying solely on Event Monitoring for a genuinely time-sensitive risk, like active data exfiltration in progress, would only discover the issue after the data had already been exported, while a properly configured Transaction Security Policy could have actually prevented that same export from completing in the first place.

Hardcoding credentials directly inside a Flow's configuration creates a genuine security liability because those sensitive credential values become visible to anyone with edit access to that specific Flow, and potentially anyone reviewing exported metadata or Change Sets (Module 23) containing that Flow, significantly widening the exposure surface for credentials that should genuinely be tightly restricted. It also creates a genuine maintenance liability because if that external system's credentials ever need to change, such as during a routine password rotation or after a security incident, an Admin would need to locate and manually update every single place those hardcoded credentials appear across potentially many different Flows, Apex classes, or other configuration, with real risk of missing an instance and leaving stale, broken, or insecure credentials in place somewhere. A Named Credential addresses both concerns simultaneously by storing the authentication details securely in one centralized location, referenced by NAME from Flow or Apex rather than containing the actual sensitive values directly — this means the credentials themselves are never exposed within the Flow's own visible configuration, and updating them once in the Named Credential automatically applies that update everywhere it is referenced, eliminating both the security exposure and the maintenance burden of hunting down scattered hardcoded values.

A comprehensive audit begins by revisiting the Phase 1 foundation directly — confirming Password Policies and Session Settings remain appropriately configured, auditing whether any non-Admin Profile has accumulated Modify All Data or View All Data over time, verifying the Role Hierarchy still genuinely reflects the organization's actual current reporting structure rather than a now-outdated snapshot, and reviewing whether existing Sharing Rules still serve a genuine, current business need rather than having simply been forgotten and left running indefinitely. This foundational review is then combined with this module's advanced tooling: running Health Check to get an automated, scored assessment of settings-based configuration and addressing flagged items; evaluating whether genuinely sensitive fields warrant Shield Platform Encryption; confirming Field Audit Trail retention meets any actual regulatory requirements the organization is subject to; verifying Event Monitoring is not just technically enabled but genuinely being reviewed on an ongoing basis; confirming Transaction Security Policies cover the organization's highest-risk real-time scenarios; and verifying every external integration uses Named Credentials with zero hardcoded credentials anywhere in the org's configuration. Security must be treated as an ongoing practice rather than a one-time setup specifically because organizations genuinely change over time — new employees join with new Role Hierarchy positions, new integrations get built, new sensitive data gets introduced, and a security configuration that was entirely appropriate at initial setup can quietly become inadequate or even actively risky as the org evolves without anyone deliberately revisiting it, which is exactly why this kind of comprehensive, periodic audit is a genuine, recurring Admin responsibility rather than a checkbox completed once during initial implementation.