@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-org-assessment-skill/references/tech-debt-indicators.md

@@ -0,0 +1,252 @@
+# Tech Debt Indicators Reference
+
+Common technical debt patterns in Salesforce orgs with detection queries,
+severity assessment, and remediation approaches.
+
+---
+
+## 1. Hardcoded IDs in Metadata
+
+### Description
+Salesforce record IDs (15 or 18 character) embedded in Apex code, Flows,
+Validation Rules, Formula fields, or Custom Settings.
+
+### Why It Creates Debt
+- IDs differ between sandboxes and production.
+- IDs become stale when records are deleted and recreated.
+- Forces code change for what should be a configuration change.
+
+### Detection
+```bash
+# Find hardcoded IDs in Apex
+grep -rn "[0-9A-Za-z]\{15\}\|[0-9A-Za-z]\{18\}" \
+  --include="*.cls" \
+  force-app/main/default/classes/ | \
+  grep -v "//\|test\|mock" | \
+  grep -E "[0-9][A-Za-z]{2}[0-9A-Za-z]{12}"
+```
+
+**PMD Rule:** `AvoidHardcodingId`
+
+### Remediation
+Replace with dynamic resolution:
+```apex
+// Replace this:
+Id supportQueueId = '00G0000000XYZabc';
+
+// With this:
+Id supportQueueId = [SELECT Id FROM Group WHERE Name = 'Support Queue' AND Type = 'Queue' LIMIT 1].Id;
+
+// Or use Custom Metadata for org-portable config:
+OrgConfig__mdt config = [SELECT SupportQueueId__c FROM OrgConfig__mdt WHERE DeveloperName = 'Default' LIMIT 1];
+Id supportQueueId = config.SupportQueueId__c;
+```
+
+---
+
+## 2. Deprecated Metadata (Workflow Rules, Process Builder)
+
+### Detection Queries
+
+```sql
+-- Active Workflow Rules
+SELECT Id, Name, TableEnumOrId, Description
+FROM WorkflowRule
+WHERE Active = true
+ORDER BY TableEnumOrId
+
+-- Active Process Builder
+SELECT Label, ApiName, LastModifiedDate, Status
+FROM FlowDefinition
+WHERE ProcessType = 'Workflow'
+  AND Status = 'Active'
+ORDER BY Label
+```
+
+### Debt Score by Count
+
+| Active Workflow Rules | Tech Debt Level |
+|----------------------|----------------|
+| 0 | None |
+| 1-10 | Low |
+| 11-50 | Medium |
+| > 50 | High |
+
+---
+
+## 3. Managed Package Lag
+
+### Description
+Installed AppExchange packages that have not been updated to recent versions
+accumulate API compatibility risks and security vulnerabilities.
+
+### Detection
+```sql
+SELECT SubscriberPackage.Name,
+       SubscriberPackageVersion.MajorVersion,
+       SubscriberPackageVersion.MinorVersion,
+       SubscriberPackageVersion.PatchVersion,
+       SubscriberPackageVersion.ReleaseState
+FROM InstalledSubscriberPackage
+ORDER BY SubscriberPackage.Name
+```
+
+### Lag Assessment
+
+| Versions Behind Current Release | Risk Level |
+|--------------------------------|-----------|
+| 0-1 minor | Low |
+| 2-3 minor | Medium |
+| 1+ major | High |
+| 2+ major | Critical |
+
+### Remediation
+1. Check the AppExchange listing for the package for current version.
+2. Review the package's release notes for breaking changes.
+3. Test upgrade in full sandbox.
+4. Schedule production upgrade during change window.
+
+---
+
+## 4. Custom Field Bloat
+
+### Detection
+
+```apex
+// Anonymous Apex: field count per custom object
+List<String> bloatedObjects = new List<String>;
+for (Schema.SObjectType objType : Schema.getGlobalDescribe.values) {
+    Schema.DescribeSObjectResult describe = objType.getDescribe;
+    if (!describe.isCustom) continue;
+    Integer fieldCount = describe.fields.getMap.size;
+    if (fieldCount > 80) {
+        bloatedObjects.add(describe.getName + ': ' + fieldCount + ' fields');
+    }
+}
+for (String entry : bloatedObjects) System.debug(entry);
+```
+
+### Standard Object Thresholds
+
+| Object | Warning Threshold | Critical Threshold |
+|--------|------------------|--------------------|
+| Account | 80 fields | 150 fields |
+| Contact | 60 fields | 120 fields |
+| Opportunity | 70 fields | 140 fields |
+| Lead | 50 fields | 100 fields |
+| Case | 50 fields | 100 fields |
+
+### Finding Orphaned Fields (Unused)
+
+Use Salesforce Optimizer (Setup > Salesforce Optimizer) to generate a field
+usage report. Fields with 0% usage in reports, list views, and page layouts
+for > 6 months are candidates for archival and deletion.
+
+---
+
+## 5. Test Coverage Below Threshold
+
+Salesforce requires 75% aggregate Apex code coverage to deploy to production.
+Best practice is 85%+ with meaningful assertions.
+
+### Detection
+```sql
+SELECT PercentCovered
+FROM ApexOrgWideCoverage
+```
+
+For per-class coverage:
+```sql
+SELECT ApexClassOrTrigger.Name, NumLinesCovered, NumLinesUncovered,
+       (NumLinesCovered / (NumLinesCovered + NumLinesUncovered + 0.0001)) * 100 AS CoveragePercent
+FROM ApexCodeCoverageAggregate
+ORDER BY CoveragePercent ASC
+LIMIT 50
+```
+
+### Quality Indicators of Test Coverage
+
+Low coverage is not the only indicator of poor testing quality:
+- Tests with 0 assertions (`System.assert` calls) — these cover lines but
+  verify nothing.
+- Tests that never test failure scenarios.
+- Tests that use `SeeAllData=true` (indicates tests are not isolated).
+
+```sql
+-- Find test classes with SeeAllData=true (isolation debt)
+SELECT Id, Name, Body
+FROM ApexClass
+WHERE Name LIKE '%Test%'
+  AND Body LIKE '%SeeAllData=true%'
+```
+
+---
+
+## 6. Excessive Use of `System.debug`
+
+### Description
+Large volumes of debug statements slow Apex execution (debug logging has I/O
+cost) and make logs unusable for diagnosis. PMD flags `System.debug` without
+a logging level.
+
+### Detection
+```bash
+grep -rn "System.debug(" --include="*.cls" force-app/ | \
+  grep -v "LoggingLevel\." | wc -l
+```
+
+More than 200 ungoverned debug statements in production code is a MEDIUM finding.
+
+### Correct Pattern
+```apex
+// WRONG: ungoverned
+System.debug('Processing account: ' + acc.Id);
+
+// CORRECT: use appropriate level
+System.debug(LoggingLevel.DEBUG, 'Processing account: ' + acc.Id);
+System.debug(LoggingLevel.WARN, 'Account has no owner: ' + acc.Id);
+System.debug(LoggingLevel.ERROR, 'Failed to update account: ' + err.getMessage);
+```
+
+---
+
+## 7. No Trigger Handler Pattern
+
+### Description
+Trigger logic written directly in `.trigger` files rather than in handler
+classes. Makes unit testing, extension, and refactoring difficult.
+
+### Detection
+```bash
+# Find trigger files with more than 20 non-blank lines of logic
+for f in force-app/main/default/triggers/*.trigger; do
+    lines=$(grep -v "^[[:space:]]*$\|^//\|^trigger" "$f" | wc -l)
+    if [ "$lines" -gt 20 ]; then
+        echo "$f: $lines lines of logic in trigger body"
+    fi
+done
+```
+
+### Remediation
+Refactor to Trigger Handler pattern:
+- Trigger file: <= 10 lines (just routing calls to handler).
+- Handler class: all business logic, unit-testable in isolation.
+- See `apex-anti-patterns.md` for trigger handler pattern example.
+
+---
+
+## Tech Debt Summary Dashboard
+
+| Indicator | Query/Check | Healthy | Warning | Critical |
+|-----------|------------|---------|---------|---------|
+| Workflow Rules | COUNT active | 0 | 1-20 | > 20 |
+| Process Builder | COUNT active | 0 | 1-10 | > 10 |
+| Apex test coverage | ApexOrgWideCoverage | > 85% | 75-85% | < 75% |
+| Hardcoded IDs in code | PMD scan count | 0 | 1-5 | > 5 |
+| Account custom fields | COUNT fields | < 80 | 80-120 | > 120 |
+| Package lag | Max major versions behind | 0 | 1 | > 1 |
+| Apex API versions | Minimum version | > 55.0 | 45-55 | < 45 |
+| Tests with SeeAllData | COUNT | 0 | 1-5 | > 5 |
+
+API version thresholds should be updated relative to current
+Salesforce release at assessment time.

package/skills/salesforce/salesforce-permission-model-review-skill/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: salesforce-permission-model-review-skill
+description: Use this skill when Salesforce profiles, permission sets, permission set groups, permission set licenses, muting permission sets, sharing rules, OWD, role hierarchy, IP restrictions, or session policies must be reviewed for toxic combinations and over-privilege. Flags: ModifyAllData with broad assignment, ViewAllData on PII objects, API Enabled without IP restriction, Customize Application outside admin profiles, and sharing-rule widening on regulated-data objects. Trigger phrases: "review this permission model", "check for toxic permission combinations", "is this permission set safe", "review sharing rules on this object", "assess our OWD and role hierarchy". Do not use when you need a full org posture review (use salesforce-org-assessment-skill), when metadata quality is the focus (use salesforce-metadata-review-skill), or when a live permission change is being proposed (use salesforce-live-change-approval-protocol). Works from sanitized exports only; never requests live org access.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-20"
+  category: security
+  lifecycle: experimental
+---
+
+# Salesforce Permission Model Review Skill
+
+## Purpose
+This skill reviews the Salesforce permission model — profiles, permission sets,
+permission set groups, permission set licenses, muting permission sets, sharing
+rules, OWD, role hierarchy, IP restrictions, and session policies — for
+over-privilege, toxic combinations, and sharing design risk. It flags
+combinations that create security or compliance exposure and produces a
+structured findings report. It does not access live orgs or authorize changes.
+
+## When to use
+- A permission audit is required before a compliance review or certification.
+- A new permission set or profile is being designed and needs adversarial review.
+- Guest-user access patterns or sharing rule changes need security review.
+- A toxic-permission alert has been raised and must be investigated.
+
+## When not to use
+- Full org posture assessment — use `salesforce-org-assessment-skill`.
+- Metadata quality review (fields, layouts) — use `salesforce-metadata-review-skill`.
+- Live permission change proposal — use `salesforce-live-change-approval-protocol`.
+- Data exposure event response — use `salesforce-data-exposure-escalation-protocol`.
+
+## Minimum payload (required inputs)
+- Sanitized permission exports: profile XML, permission set XML, permission set
+  group definitions, sharing rule definitions, OWD settings, role hierarchy
+  summary, IP restriction settings, session policy settings.
+- Context: approximate user population, key regulated-data objects, industry vertical.
+
+## Workflow
+
+### 1. Profile review
+- List all profiles and their base permissions.
+- Flag: `ModifyAllData` assigned to any non-system-admin profile.
+- Flag: `ViewAllData` on profiles with access to PII-classified objects.
+- Flag: `API Enabled` on profiles without corresponding IP restriction.
+- Flag: `Customize Application` on profiles outside the designated admin group.
+- Flag: `Manage Users` outside HR/IT admin profiles.
+- Flag: profiles with direct object-level Create/Edit/Delete on financial or
+  regulated-data objects without documented business justification.
+
+### 2. Permission set review
+- List all permission sets and their grants.
+- Flag: permission sets granting `ModifyAllData` or `ViewAllData` that are
+  assigned broadly (> configurable user threshold).
+- Flag: permission sets duplicating profile permissions (redundant, adds attack surface).
+- Flag: permission sets with no current assignees (orphaned — attack surface if reassigned).
+- Flag: `Field Service`
+or
+  `Experience Cloud`
+permission sets
+  granting object access beyond their intended scope.
+
+### 3. Permission set groups and muting
+- Review permission set group composition.
+- Flag: muting permission sets that silently narrow permissions without clear documentation.
+- Flag: permission set groups that combine permissions creating toxic combinations.
+
+### 4. Sharing model review
+- Review OWD (Organization-Wide Defaults) per object.
+- Flag: OWD = Public Read/Write on objects containing PII or financial data.
+- Flag: OWD = Public Read Only on regulated-data objects where stricter control is expected.
+- Review role hierarchy: flag roles that grant data access beyond job function.
+- Review sharing rules:
+  - Flag: criteria-based rules that are effectively always-true.
+  - Flag: sharing rules on objects classified as regulated data.
+  - Flag: sharing rules granting Edit access where Read is sufficient.
+
+### 5. Guest user review
+- Review guest-user profile permissions (Experience Cloud
+).
+- Flag: guest-user profile with any object-level Read access to records containing PII.
+- Flag: sharing sets that grant guest users access to records via lookup relationships
+  that could expose unintended records.
+- Flag: public-site access (Sites
+) with
+  Apex REST endpoints lacking CSRF protection.
+
+### 6. IP restrictions and session policies
+- Flag: named credentials or connected apps without IP allowlisting in production.
+- Flag: session timeout > configurable threshold for privileged user groups.
+- Flag: `Lock sessions to the IP address from which they originated` disabled
+  for profiles with sensitive permissions.
+
+## Toxic combination registry
+These specific combinations always produce a Critical or High finding:
+
+| Combination | Risk | Rating |
+|---|---|---|
+| `ModifyAllData` + broad assignment (> threshold users) | Mass data destruction or exfiltration | Critical |
+| `ViewAllData` + PII object access + no IP restriction | PII exposure | Critical |
+| `API Enabled` + no IP restriction + sensitive object access | API-based data exfiltration | High |
+| `Customize Application` + non-admin profile | Privilege escalation via metadata change | High |
+| `Manage Users` + no IP restriction | Account takeover / privilege escalation | High |
+| Guest user + sharing set + PII object | Unauthenticated PII exposure | Critical |
+| `ModifyAllData` + `Manage Users` on same profile | Full org compromise posture | Critical |
+
+## Evidence requirements
+- Sanitized permission exports; no credentials, session tokens, or customer data.
+- OWD settings and role hierarchy summary are required for sharing model review.
+- User assignment counts (not names) are required for broad-assignment checks.
+
+## Output format
+```
+permission_model_findings:
+  profile_findings:
+    - finding: [description]
+      severity: Critical | High | Medium | Low
+      combination: [which toxic combination, if applicable]
+      evidence: [what in the export supports this]
+      recommendation: [brief]
+  permission_set_findings: [same structure]
+  sharing_model_findings: [same structure]
+  guest_user_findings: [same structure]
+  ip_session_findings: [same structure]
+
+toxic_combinations_detected: [list from registry]
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+summary:
+  critical_count: [count]
+  high_count: [count]
+assumptions: [list]
+missing_evidence: [what would improve the review]
+```
+
+## Redaction rules
+- Never request secrets, credentials, OAuth tokens, refresh tokens, session IDs, MFA seeds, customer PII.
+- Sanitize org IDs, user IDs (replace with placeholders) before sharing in outputs.
+- Do not include actual user names; use role and count references only.
+
+## Privilege / data handling rules
+- Permission review findings involving regulated data must be flagged for compliance specialist review.
+- Guest-user findings involving PII must trigger salesforce-data-exposure-escalation-protocol.
+
+## Handoff rules
+- Hands off to: salesforce-org-assessment-skill (full posture context),
+  salesforce-data-exposure-escalation-protocol (if guest-user PII exposure confirmed),
+  salesforce-case-capsule (structured handoff for any Critical finding).
+- Required handoff fields: matter_id, toxic_combinations_detected, escalation_gates_fired,
+  critical_count, assumptions.
+
+## Audit log fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- Export contains live credentials or session tokens — stop and ask for sanitized version.
+- Guest-user PII exposure is confirmed — stop, output ESCALATE, invoke salesforce-data-exposure-escalation-protocol.
+- Critical toxic combination detected in a production org — stop and require human review before continuing.
+
+## Security notes
+- Read-only static review; never requests live org access or runs SOQL queries.
+- Sanitized inputs only; any input containing credentials must be refused.
+- Toxic combinations are objective findings; remediation requires human-authorized change management.
+- Guest-user exposure is always escalation-grade regardless of record count.

package/skills/salesforce/salesforce-permission-model-review-skill/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "salesforce-permission-model-review-skill",
+  "name": "Salesforce Permission Model Review Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Reviews Salesforce profiles, permission sets, permission set groups, muting, sharing rules, OWD, role hierarchy, IP restrictions, and session policies for toxic combinations and over-privilege, flagging ModifyAllData, ViewAllData on PII, API Enabled without IP restriction, guest-user exposure, and Customize Application outside admins.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.salesforce.com/",
+    "https://developer.salesforce.com/docs"
+  ],
+  "security_notes": "Read-only static review; sanitized exports only; never requests live org credentials or API access. Guest-user PII exposure always triggers escalation-protocol. Toxic combinations are objective findings requiring human-authorized remediation.",
+  "last_verified": "2026-05-20",
+  "path": "skills/salesforce/salesforce-permission-model-review-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/salesforce/salesforce-permission-model-review-skill/references/fls-review-patterns.md

@@ -0,0 +1,235 @@
+# FLS Review Patterns Reference
+
+Field-Level Security review patterns for identifying and remediating
+unauthorized access to PII, encrypted fields, and regulated data in Salesforce.
+
+---
+
+## What Field-Level Security Controls
+
+Field-Level Security (FLS) determines which fields a user can read or edit
+on an object. It operates independently from record sharing:
+- **Record sharing** controls whether a user can see the record at all.
+- **FLS** controls which fields within an accessible record the user can see or edit.
+
+A user might have read access to a Contact record but FLS may hide the
+SSN__c field for that user's profile/permission set configuration.
+
+---
+
+## FLS Enforcement Gaps in Apex
+
+The most common FLS gap is Apex code that queries and returns fields without
+checking whether the running user has FLS access to those fields.
+
+### Why Apex Bypasses FLS By Default
+
+SOQL executed in Apex system context returns all fields regardless of FLS.
+Even `with sharing` only enforces row-level access, not field-level access.
+
+### Detection: Find @AuraEnabled Methods Returning Sensitive Fields
+
+```bash
+# Find Apex methods that return Contact with SSN or financial fields
+grep -rn "SSN__c\|CreditScore__c\|BankAccount__c\|TaxId__c" \
+  --include="*.cls" \
+  force-app/main/default/classes/
+```
+
+Then check each result for the presence of FLS enforcement:
+```bash
+# Verify Security.stripInaccessible or WITH SECURITY_ENFORCED nearby
+grep -A5 -B5 "SSN__c" force-app/main/default/classes/ContactController.cls | \
+  grep -E "stripInaccessible|SECURITY_ENFORCED|isAccessible"
+```
+
+---
+
+## FLS Enforcement Methods
+
+### Method 1: WITH SECURITY_ENFORCED in SOQL
+
+```apex
+// Throws QueryException if user lacks FLS read on any field in SELECT
+@AuraEnabled
+public static List<Contact> getSensitiveContacts {
+    return [
+        SELECT Id, Name, Email, SSN__c, TaxId__c
+        FROM Contact
+        WITH SECURITY_ENFORCED
+        LIMIT 100
+    ];
+}
+```
+
+**Limitation:** If the field is in the SELECT clause and the user lacks access,
+the entire query throws an exception. This is all-or-nothing — you cannot
+selectively strip one field and return the rest with this approach.
+
+### Method 2: Security.stripInaccessible
+
+```apex
+@AuraEnabled
+public static List<Contact> getSensitiveContacts {
+    // Query without FLS enforcement first
+    List<Contact> rawContacts = [
+        SELECT Id, Name, Email, SSN__c, TaxId__c
+        FROM Contact
+        LIMIT 100
+    ];
+
+    // Strip fields the running user cannot read
+    SObjectAccessDecision decision = Security.stripInaccessible(
+        AccessType.READABLE,
+        rawContacts
+    );
+
+    // Returns records with inaccessible fields removed
+    return (List<Contact>) decision.getRecords;
+}
+```
+
+`stripInaccessible` strips fields silently rather than throwing an exception.
+The returned records simply do not have the restricted field populated.
+
+### Method 3: WITH USER_MODE (API 57.0+)
+
+```apex
+// Runs query entirely in user context: sharing rules + FLS + CRUD all enforced
+@AuraEnabled
+public static List<Contact> getSensitiveContacts {
+    return [
+        SELECT Id, Name, Email, SSN__c
+        FROM Contact
+        WITH USER_MODE
+        LIMIT 100
+    ];
+}
+```
+
+`WITH USER_MODE` is the most comprehensive enforcement — use this when possible
+in new code (Salesforce API version 57.0 and above).
+
+### Method 4: Manual FLS Check
+
+```apex
+public static Boolean canReadField(SObjectType objType, String fieldApiName) {
+    return objType.getDescribe
+        .fields
+        .getMap
+        .get(fieldApiName)
+        ?.getDescribe
+        .isAccessible ?? false;
+}
+
+// Usage
+if (!canReadField(Contact.SObjectType, 'SSN__c')) {
+    throw new AuraHandledException('You do not have access to this information.');
+}
+```
+
+---
+
+## PII Field Classification for FLS Review
+
+### High-Priority Fields Requiring Restrictive FLS
+
+| Object | Field API Name Pattern | Classification |
+|--------|----------------------|----------------|
+| Contact, Lead, Individual | `SSN__c`, `NationalId__c`, `TaxId__c` | Restricted PII |
+| Contact | `BirthDate` | Sensitive PII |
+| Contact, Account | `CreditScore__c`, `BankAccount__c` | Financial PII |
+| HealthCloudGA__EhrPatient__c | All fields | PHI (HIPAA) |
+| FinServ__FinancialAccount__c | `FinServ__Balance__c`, account number fields | Financial PII |
+| Contact | `Password__c`, `SecurityAnswer__c` | Credential (should not exist in Salesforce) |
+| Contact | `PassportNumber__c`, `DriversLicense__c` | Government ID |
+
+### Standard Fields Requiring FLS Review
+
+| Object | Field | Caution |
+|--------|-------|---------|
+| User | `Username`, `Email` | Identity data; restrict from non-admin users |
+| Contact | `Email` | Core PII; verify FLS aligns with consent model |
+| Lead | `Email`, `Phone` | Contact data; restrict edit to owners |
+
+---
+
+## FLS Audit Queries
+
+### Find Fields Without FLS Restrictions (All Profiles Can Read)
+
+```apex
+// Check FLS for a specific field across all active profiles
+String objectApiName = 'Contact';
+String fieldApiName = 'SSN__c';
+
+List<FieldPermissions> fps = [
+    SELECT Id, Parent.Label, Field, PermissionsRead, PermissionsEdit
+    FROM FieldPermissions
+    WHERE SobjectType = :objectApiName
+      AND Field = :(objectApiName + '.' + fieldApiName)
+    ORDER BY Parent.Label
+];
+
+for (FieldPermissions fp : fps) {
+    if (fp.PermissionsRead) {
+        System.debug('READ ACCESS: ' + fp.Parent.Label + ' -> ' + fp.Field);
+    }
+}
+```
+
+### Find Profiles with Broad Field Access
+
+```sql
+-- Via SOQL: identify Permission Sets with read access to sensitive fields
+SELECT Parent.Label, Field, PermissionsRead, PermissionsEdit
+FROM FieldPermissions
+WHERE SobjectType = 'Contact'
+  AND Field IN ('Contact.SSN__c', 'Contact.TaxId__c', 'Contact.BankAccount__c')
+  AND PermissionsRead = true
+ORDER BY Parent.Label
+```
+
+---
+
+## FLS Review Checklist by Data Type
+
+### For Each Regulated/Sensitive Object
+
+- [ ] Default FLS for sensitive fields is Read=false, Edit=false on all profiles.
+- [ ] Access to sensitive fields granted only via named Permission Sets.
+- [ ] Permission Sets granting field access have documented business justification.
+- [ ] Number of users with field access is documented and reviewed annually.
+- [ ] Apex code querying sensitive fields uses `stripInaccessible`, `WITH SECURITY_ENFORCED`, or `WITH USER_MODE`.
+- [ ] LWC components receiving sensitive field data enforce FLS at the Apex layer.
+- [ ] Reports using sensitive fields are in restricted-access report folders.
+
+### For @AuraEnabled Methods Returning SObjects
+
+- [ ] Method uses `with sharing` on the class.
+- [ ] Method uses at least one FLS enforcement mechanism (see Method 1-3 above).
+- [ ] Method does not log sensitive field values to `System.debug`.
+- [ ] Method does not include sensitive fields in error messages returned to the UI.
+
+---
+
+## FLS and Report Access
+
+FLS applies to reports: users without FLS read access to a field cannot add
+that field to a report. However, if a report was saved by an admin who had
+access, and then shared with a user who lacks FLS access, the behavior varies
+by report type.
+
+**Recommendation:** Store reports containing sensitive fields in folders with
+restricted access matching the FLS grant.
+
+```sql
+-- Find report folders with their access levels
+SELECT Id, Name, AccessType, DeveloperName
+FROM Folder
+WHERE Type = 'Report'
+ORDER BY AccessType, Name
+```
+
+`AccessType = 'Public'` means all users can access reports in this folder —
+review whether any report in a public folder contains restricted fields.