I would have separate views (eg table PERSON with PERSON_BASIC having no PII columns and PERSON_PII with the PII columns). That way, if it is later decided that a column is sensitive (eg Date of Birth), then you can easily recreate the views to remove the column from the basic view rather than some massive data restructuring exercise which you would get with separate tables.
Also, the optimizer is getting better at correlation between columns on the same table (and you'd expect that to improve over time). Once you start joining non-PII tables to PII tables, you've just made it more complicated.
If you do go for separate tables, and think they'll need to be joined often, look into clusters so that the records for the same person are on the same block.
Consider using a role secured by a password or through a package to control access to the PII view/columns.
CONTEXT can do this too. They are forced to call the package to set the context before they see the columns.
The view could be
SELECT name, date_of_birth,
case when SYS_CONTEXT('SEC','xxx') ='ALLOW' THEN ssn END
from ...