Describe how you would extend an internal security model to a partner community without weakening internal access.

The starting point is that external access is governed separately. Each object has an external organization-wide default alongside the internal one, and it cannot be less restrictive than the internal setting — so external access is a distinct decision, not a side effect of the internal model.

My approach:

1. Set the external OWD to Private on every object partners can reach, then open specific access deliberately.
2. Choose the license by required behaviour: Partner Community or Customer Community Plus if partners need their own hierarchy and sharing rule participation; Customer Community with sharing sets if the population is high-volume and each user only needs their own account's records.
3. Use the account role hierarchy so a partner manager sees records owned by users beneath them within their own partner account, and no further.
4. Use sharing sets rather than sharing rules for high-volume users, and share groups so internal staff can see records those external users own.
5. Review field-level security separately for external profiles, because internal-only fields on shared objects are the most common leak.

Then I test with a real partner user in a full-copy sandbox against the persona matrix, because reasoning about external sharing on paper is unreliable.