Você precisaria de gatilhos para inserir "automaticamente" o registro em uma tabela separada.

Inserir o registro em UserPrivacy com uma consulta separada seria a maneira mais comum de implementar isso.

Se for um relacionamento um para um, colocá-lo na mesma tabela permite consultas mais simples (sem necessidade de junção).

Decisões, Decisões...

Com uma relação de um para (zero para um), há mais fatores a serem considerados.

Se a tabela UserPrivacy for grande, talvez faça sentido colocá-la em uma tabela separada para economizar espaço. Isso também seria mais normalizado.

Se você costuma consultar algo como "Dê-me todos os usuários que não têm PrivacyData", pode fazer sentido colocá-lo em uma tabela separada. Como os índices não incluem valores NULL (por padrão), seria mais rápido fazer um JOIN em uma tabela separada. Claro, a solução é usar um valor diferente de NULL para representar "nenhuma configuração de privacidade", mas a baixa cardinalidade também afeta negativamente o desempenho. Tabelas separadas seriam melhores para este caso.

Além disso, se os dados de privacidade fossem atualizados com frequência, mas não os dados do usuário, tabelas separadas evitariam bloqueios de linha na tabela do usuário e as atualizações são mais rápidas em tabelas menores, o que pode melhorar o desempenho.

Se você frequentemente precisa dos dados UserPrivacy sem UserData, ou vice-versa, convém separá-los.

Ainda assim, isso pode ser uma otimização prematura. Você pode apenas querer separá-los se eles corresponderem melhor aos seus modelos. Considere a simplicidade de mantê-lo na mesma tabela versus os problemas de desempenho, tamanho e legibilidade.

Se o relacionamento fosse de um para (zero para muitos), você obviamente desejaria uma tabela separada, mas para um para-(zero para um), é opcional.

Finalmente...

Não tenha medo de separá-los, desde que haja um motivo.