Public access becomes risky when custom records hold sensitive, operational, or financially relevant data, because every user can then view and modify those instances. If the record contains business process data, customer details, or restricted internal information, defaulting to no permission required is usually too broad. Access should match the record’s sensitivity and the business need for sharing.
Why public access becomes unacceptable in practice
Public access is not inherently wrong, but it stops being acceptable when the record contains information that should not be broadly readable or editable by every user in the account. The core issue is not just exposure, it is also integrity: if anyone can change the instance, the record can no longer be trusted as a controlled business object.
That is why the same access model can be harmless for low-sensitivity reference data and unsafe for records that drive operations, approvals, customer handling, finance, or internal workflows. Once the record influences decisions or contains restricted details, open access creates an avoidable control gap.
A useful test is whether a normal employee, contractor, or external user could learn something or make a change that would alter business outcomes without an explicit business reason. If the answer is yes, the default permission model is already too broad.
What kinds of custom records are most exposed
Risk rises sharply when custom record instances hold customer information, case notes, pricing, billing, exceptions, operational status, or other records that map to a live business process. Those records often look low risk at design time, but they become sensitive once they are populated with real operational content.
Open access also becomes problematic when records are used as a lightweight substitute for a workflow system or internal register. In that pattern, the record often becomes the place where teams store approvals, escalations, sensitive comments, or decision rationale, which means the data is more sensitive than the schema suggests.
Records that appear harmless in isolation can also become risky when combined with other fields or related data. A few nonsensitive attributes may still reveal internal structure, customer relationships, transaction patterns, or exceptions that should not be visible to all users.
How to judge whether sharing is justified
Public access is only defensible when the record is genuinely intended to be shared across a broad population and the data inside it is suitable for that audience. The decision should be based on the record’s actual contents and business purpose, not on convenience or the assumption that open access will reduce support requests.
When access is needed, the better pattern is to scope it to a role, audience, or business process that matches the record’s sensitivity. In many cases, read access and write access should not be treated the same way, because the ability to change a record is usually more dangerous than the ability to view it.
If the business wants broad visibility, the safer design is often to separate public summary data from restricted operational details. That preserves usefulness without exposing the fields that create the real risk.
Risk and Threat Considerations
When custom records are publicly accessible, the main failure mode is overexposure plus unauthorized modification. Sensitive or operational data can be viewed too widely, and if write access is also open, records can be corrupted, manipulated, or used to mislead downstream users and processes.
Failure mechanism: Excessively broad record permissions allow any user with platform access to read or alter instances, which can expose restricted information or undermine the integrity of business data.
Impact: The organisation can suffer confidentiality loss, incorrect decisions, workflow disruption, customer harm, and in some cases financial or compliance exposure if the records contain regulated or business-critical content.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Broad public record access is an access-minimization problem. |
| Recommendation — Limit record visibility and edit rights to the minimum required by role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about whether access to records is too broad for their sensitivity. |
| Recommendation — Define and enforce access rules that match record sensitivity and business need. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Custom record public access hinges on controlling who can read and change business data. |
| Recommendation — Review and restrict access paths for records that contain sensitive or operational data. | ||
| OWASP ASVS | V8 — Authorization | The issue is whether access to application data is appropriately authorized. |
| Recommendation — Verify that only intended users can view or modify protected record instances. | ||
Practitioner Guidance
What to verify: Confirm whether the custom record stores operational, customer, financial, or internal decision data, then separate the view question from the edit question. A record that is safe to display is not automatically safe to modify.
Decision rule: If the record can influence a business process, approval, entitlement, payment, or customer outcome, treat public access as a high-risk default and require a narrower audience or explicit exception.
What good looks like: Public access is limited to records whose fields are intentionally shareable, while sensitive fields remain restricted or split into a separate object with tighter permissions.
Practitioner takeaway: The key judgment is not whether the record is custom, it is whether the instance can reveal or change something the business would not want every user to see or alter.
