It's hard to prove a practice is industry standard, but I will present some scenarios I have come across.
Let's look at some of your constraints:
- The users should be presented only with their own PII when using the system
- Users should not be able to search for other users' PII
- Users do not necessarily know or remember the ID (key) they have been assigned
Your scenario of 10 randomly permutted profile info doesn't look acceptable, especially if it reveals actual PII without authentication -- someone knowing the person will recognise it, for example, or they may validate a profile is real by cross-referencing against other leaked PII databases. It may well break data protection regulations.
It sounds like your organisation already provisioned users accounts to store their PII and keyed it with a globally unique ID. You will need to come up with an authentication system that will help your users to log in and access their provisioned information. This system should allow a variety of authentication scenarios since not all users will be able to use their assigned ID.
Log in using the globally unique ID
This is a common scenario with organisations, however not necessarily the easiest. Typically, before the user interacts for the first time with the online platform, the organisation will most probably have been in touch with them through other means.
If your organisation is in communication with the user through any means (e.g. email, or postal mail), it may be a good idea to proactively specify the globally unique ID, for example as a header, as this should help with the "forgetting the ID" problem. Knowing this information, the user should be able to request a temporary password being sent through the same channel to claim the provisioned account.
The claiming process may include verifying the PII.
Log in using an email or a telephone number
Now, supposing that the users don't know their assigned globally unique ID, they should however know their own email address or phone number.
If a user inputs their phone number or email, you can search and match that against the database. If there is a match (i.e. the offline data gathering and digital entry worked without error), then you may send a temporary password to that same email address or phone number (e.g. as a text). It should be a safe bet to assume that they are personally in control of the email or phone number they have just entered in the system. The user may then enter this temporary password and proceed to verify and claim their user account.
You should not acknowledge any of the email address or phone number exist or don't exist in your database, however, and instead simply state an action would been taken should the entry be valid.
Some more thoughts
Now I understand I talked about "claiming a user account". I accept it can be a barrier for some users to create or otherwise possess yet again another user account and remember yet again another password, especially for something they'd log onto at most once a year. You may gauge the difficulty of requiring they set up a personal password to claim the account, but in the long run this may be beneficial -- I think the claiming process is more cumbersome than "normal" user account management, not to mention less secure.
Please note you would perhaps have to also think about a user support procedure, and hence a phone or other verification procedure.
On "temporary" passwords: you should decide if they need to be limited in time or if they'd only be deactivated once used the first time (one-time passwords).
I have also seen a process using the name and postal address as a form of identification, and the password would be sent in a letter at this address. Now I'm a bit less comfortable with this one, as it would require a manual intervention on the NGO side to assess the validity of the request -- the known name and address may differ with the information specified in the password request, so an operator should manually check if they plausibly match (i.e. different formatting, accents, etc...). This is open to human error, so I'm not recommending it, unless you have the resources and manpower to ensure it.