Philippines staffing research ·
How Much Candidate Data Does a Sourcing Coordinator Need?
A field-by-field research protocol for limiting candidate records before a hiring owner makes a selection decision.

Research question: which candidate fields does a Philippines-based sourcing coordinator need for a defined coordination task, and which fields can remain hidden until an authorized hiring owner has a documented reason to use them? This is a data-minimization question, not a proposal to rank people with fewer facts. The aim is to test whether routine scheduling, completeness checks, and follow-up can work with a narrower record while selection stays with the employer.
Why this matters to a staffing buyer: candidate files tend to expand because every form, message, and interview note is copied into one system. That is convenient, but convenience is not a purpose. A coordinator who only schedules an approved interview may need a name, contact route, time zone, role reference, availability window, and scheduling history. The same task does not automatically require government identifiers, family details, medical information, compensation history, or unrestricted interview notes.
Source basis: the Philippine Data Privacy Act defines personal information controllers and processors and recognizes outsourced processing. Its implementing rules require lawful processing, accountability, security measures, limited processing for a declared purpose, access management, retention procedures, and appropriate contracts with processors. Those provisions support asking who decides the purpose, which party follows instructions, and whether the field set is proportionate. They do not produce a universal recruiting form or settle a buyer's obligations in another jurisdiction.
Method: create a synthetic field inventory for four coordination tasks: sourcing-list preparation, interview scheduling, application-completeness review, and candidate-status follow-up. For each task, list every proposed field, its source, declared use, viewer, retention trigger, export path, and owner. Build sixty artificial candidate records containing ordinary cases, duplicated profiles, corrected contact details, scheduling accommodations, withdrawn applications, and deliberately excessive fields. Use no real candidate data.
Before review, a hiring owner and privacy owner place each field into one of four states: required for the named task, conditionally available after an approved trigger, owner-only, or excluded. Reviewers then complete the same coordination cases with the full record and with the minimized view. The codebook must explain each classification. A field cannot be called required merely because it has always appeared on a template or might be useful someday.
The primary measure is task completion without opening an owner-only field. Secondary measures are scheduling error, unnecessary disclosure, time per case, unresolved-case rate, and reviewer agreement about the correct next owner. Record false confidence as a failure: a coordinator who lacks the evidence to proceed should hold and route the case, not infer a value from a name, photograph, school, address, or prior employer.
The experiment needs negative controls. Some cases should be solvable from the narrow view. Others should contain a legitimate trigger for owner review, such as an approved accommodation process or a duplicate record that cannot safely be merged. A successful minimization rule allows ordinary coordination and stops at the right boundary. If every case passes, the test probably failed to include difficult records. If every case stops, the task design is too restrictive to be useful.
Facts and decisions remain separate. The fact that a field exists does not prove it is accurate, current, voluntarily supplied, or appropriate for selection. The fact that two profiles share a phone number does not prove duplicate identity. A coordinator may record that a required field is missing, send approved follow-up language, link a source, and route a conflict. The hiring owner decides qualifications, interview progression, rejection, compensation, and any exception to the approved process.
The access design should match the field decision. Masked display is weaker than exclusion if users can reveal or export the value without a task reason. Test list views, search results, notifications, calendar invitations, downloaded files, audit logs, and integrations. A narrow application screen does not minimize data if a spreadsheet export or email alert reproduces the full record. Document each propagation path and assign an owner to remove unnecessary copies.
Retention also needs an event, not an indefinite label. The protocol records withdrawal, role closure, duplicate resolution, legal hold, candidate request, and approved transfer as possible triggers, while the responsible owner sets the actual rule. Reviewers test whether a closed requisition still exposes records in shared folders and whether a deleted interface record remains in an export. The study reports visibility and routing. It does not authorize deletion or define a lawful retention period.
Analysis plan: compare the full and minimized views by task, not with one blended score. Report the count of cases completed, held correctly, disclosed unnecessarily, and routed to the wrong owner. Preserve the denominator and every unknown. A faster narrow view would be useful only if error and inappropriate-disclosure rates do not worsen under the preset thresholds. The owner sets those thresholds before seeing results to avoid choosing a flattering interpretation afterward.
Field requests should also be tested against plausible alternatives. A coordinator may need to distinguish candidates with similar names, but that does not mean a government identifier belongs in the scheduling view. A stable application reference may solve the problem. A team may want a home address to infer time zone, but direct availability and time-zone fields are more closely tied to scheduling. For every proposed field, reviewers document whether a less revealing value can serve the same operational purpose and what error that substitution could introduce.
The protocol treats free text as a separate risk because a narrow field label does not constrain what people type into it. Reviewers seed notes that contain an unrequested identifier, health detail, compensation history, and opinion about a candidate. They test whether the system can restrict the note, route it for owner review, and prevent it from spreading into calendars or exports. The result should show whether minimization survives real input behavior, not only whether the database schema looks tidy.
Provider comparison requires evidence from the configured workflow. A policy that says coordinators receive limited access is useful, but the buyer should also inspect a role demonstration, permission export, sample audit event, and offboarding step within an approved test environment. Each artifact answers a different question. The study records their scope and date. It does not turn a successful demonstration into proof of continuous compliance, and it does not ask staff to expose live candidate records for reassurance.
Inference boundary: results from synthetic cases can show whether a proposed field map is usable and reviewable. They cannot show how candidates experience the process, whether a field is lawful in every jurisdiction, whether the provider follows the design in production, or whether hiring outcomes are fair. Those questions require separate evidence, approved governance, and, where appropriate, qualified advice. The buyer should also verify the actual contracting and data-processing roles rather than relying on sales labels.
Limitations: artificial records are cleaner than live candidate histories. They omit identity disputes, multilingual communications, platform-specific permissions, accessibility needs, local retention duties, and information supplied outside the approved channel. Reviewers may learn the seeded patterns. A live pilot should use a small approved queue, logged access, a stop rule for unexpected sensitive data, and a way for the privacy and hiring owners to suspend the test.
Decision use: the result should be a field-to-task matrix, not a claim that less data is always better. For each field it names the purpose, viewer, trigger, destination, retention event, and accountable owner. That gives a staffing buyer something concrete to compare across providers and something a coordinator can follow on an ordinary workday. Any unresolved field stays unresolved until the designated owner decides.
Sources checked September 18, 2026: National Privacy Commission, Implementing Rules and Regulations of the Data Privacy Act of 2012 (https://privacy.gov.ph/implementing-rules-regulations-data-privacy-act-2012/); National Privacy Commission, Republic Act No. 10173, Data Privacy Act of 2012 (https://privacy.gov.ph/data-privacy-act/); Department of Labor and Employment, Labor Code of the Philippines, DOLE Edition 2022 (https://dole.gov.ph/labor-code-of-the-philippines-2/); National Institute of Standards and Technology, Cybersecurity Framework 2.0 (https://doi.org/10.6028/NIST.CSWP.29); National Institute of Standards and Technology, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, SP 1326 (https://doi.org/10.6028/NIST.SP.1326). These are primary government sources. They provide legal text and control guidance, but they do not approve a provider, interpret a particular contract, or decide an employment matter.