FAQ-000482 - Custom Settings and Configuration Security / Post-Installation Configuration and Customer Setup

When security requirements, like using protected custom settings, conflict with essential application functionality, the recommended approach is: 1. **Implement Mitigations**: Align with security standards while maintaining functionality. 2. **Document the Use Case**: Clearly explain why the functionality is essential and how it's implemented securely. 3. **Provide Admin-Configurable Options**: Allow administrators to configure settings to balance security and usability. 4. **Apply Scoped Permissions**: Use custom permission sets specific to roles or users to limit access. 5. **Perform Explicit Security Checks**: Ensure that sensitive operations are protected by additional security validations. 6. **Submit Documentation with Your Review**: Provide a detailed explanation of the implementation and use case to help reviewers assess the application effectively. This approach ensures compliance with security standards while preserving the application's functionality.

The main improvement needed is updating the outdated terminology in point 6. The phrase 'Submit a False-Positive Document' uses technical jargon that could confuse readers and implies the security concern is invalid (a 'false positive'). The updated language 'Submit Documentation with Your Review' is clearer, more direct, and accurately describes what developers need to do - provide documentation alongside their security review submission. This aligns better with the conversational, clear tone guidelines and avoids potentially confusing terminology. I selected the AvoidChangeProtectionUnprotected rule because this FAQ specifically addresses scenarios where developers might need to use unprotected custom settings (which this rule flags), and the FAQ's guidance on documentation, mitigations, and security checks directly relates to how developers should handle situations where this rule is triggered but the functionality is essential.