Chapter 6

Chapter 6: Security, Privacy, and System Integration

The earlier chapters defined what a biosafety record contains, how an incident moves through its workflow, which service interfaces expose the records, and how records travel between institutions with an audit trail. This chapter asks a different question: who is allowed to see which part of those records, and how the records get into the system in the first place. A biosafety record service is only useful if it is fed by the systems an institution already runs (human resources, learning management, access control, laboratory information management, environmental health and safety), and it is only safe if the information it concentrates does not become easier to misuse than the scattered paper files it replaced.

Two properties make this harder than ordinary enterprise data security. First, some biosafety metadata is itself sensitive for biosecurity reasons, independent of any personal data it contains. Second, the same records hold personal data about researchers, including data that can touch on health. The controls in the WIA-BIO-017 PHASE-4 document are a starting point; this chapter turns them into a concrete access model, a privacy design, and an integration pattern.

6.1 Threat Model for Biosafety Records

A threat model starts with assets, not with technologies. For a biosafety record service, the assets are the records defined in Chapters 2 and 3 and the relationships between them. Each asset carries a different kind of risk if it is disclosed, altered, or made unavailable, and the controls must be proportionate to that risk rather than uniform across the whole database.

6.1.1 Assets and why they are sensitive

The most important point, and the one most often missed by teams coming from general IT, is that aggregation creates sensitivity. A single room number on a door sign is public. A list that joins every registered containment facility in an institution to its building, room, containment level, access-control arrangement, and the registry identifiers of the materials held there is a different object. It answers the question "where, exactly, is the material of interest, and how is the room protected" in one query. Biosecurity guidance treats this kind of compiled information as an information hazard: something that is harmless piece by piece but can assist misuse when assembled. The record service is, by design, the place where these pieces are assembled, so it must treat the joined view as more sensitive than any of its parts.

Asset	Main concern	Sensitivity class (book's proposal)
Facility summary (ID, name, containment level label, certification status)	Low on its own; needed widely for scheduling and reporting	Internal
Facility location detail (location.building, location.room, location.address)	Biosecurity information hazard when joined with level and inventory references	Restricted
Access-control profile (accessControls block)	Reveals how a room is protected	Restricted
Inventory and custody references (registry IDs, transfer records from Chapter 5)	Biosecurity information hazard	Restricted
Training records	Personal data; employment consequences	Personal
Incident reports and near-miss reports	Personal data, reputational harm, chilling effect on reporting	Personal + Restricted
Occupational-health case data	Health data (special category)	Held outside the record service
Audit events	Integrity is critical; reveal who looked at what	Restricted, append-only

The sensitivity classes above are the book's proposal, not a normative part of WIA-BIO-017. The spec does not define classification labels, but an implementation needs some labeling scheme in order to enforce field-level rules, and a four-level scheme (Internal, Restricted, Personal, and "held elsewhere") is simple enough for a biosafety office to apply consistently.

6.1.2 Threat actors

Three classes of actor matter most. External attackers go after the service like any web application: credential stuffing, exploitation of unpatched components, abuse of exposed APIs. Insiders with legitimate accounts are the harder case. A researcher who is entitled to see her own laboratory's records has no need to browse the room-level details of every containment facility on campus, and an HR analyst who imports training completions has no need to read incident narratives. In record systems, over-broad legitimate access is a common route to disclosure, and it is harder to notice than a break-in. Partner institutions are the third class. They are trusted for specific exchanges (Chapter 5), but that trust does not extend to re-identifying pseudonymous personnel or to receiving fields they did not ask for.

6.1.3 Need-to-know at field level

Record-level permissions ("may read incident INC-…") are not fine-grained enough. The same incident report contains an administrative core that the IBC must see, a narrative that the investigation team must see, and a list of personnel identifiers that only the biosafety officer should be able to resolve to names. The design principle is therefore need-to-know at field level: every field is tagged with its sensitivity class, every role is granted classes rather than whole records, and the API projects each record down to the fields the caller's role allows before it is serialized. A caller who is not entitled to a field does not receive it as null, which would be indistinguishable from a genuinely empty value, but simply does not receive the key at all, and the response carries a list of withheld field paths so that client software can show "restricted" instead of silently rendering an incomplete form.

6.2 Security Controls from PHASE-4

The PHASE-4 integration document lists a compact set of security controls: encryption at rest with AES-256, encryption in transit with TLS 1.3, role-based access control with multi-factor authentication, comprehensive audit logging, and API authentication by OAuth 2.0 plus API keys. These are sensible baseline choices. What the document does not specify is how they fit together for biosafety data, and that is what an implementer actually needs.

6.2.1 Encryption at rest and in transit

AES with 256-bit keys, used in an authenticated mode such as GCM, is the conventional choice for data at rest. The practical questions are about keys, not algorithms. Keys belong in a key-management service or hardware security module, not in configuration files next to the database. Restricted fields (facility location detail, access-control profiles, inventory references) benefit from an additional layer of application-level envelope encryption with a separate key, so that a database administrator who can read tables does not automatically read those fields. Backups inherit the same classification as the live data and must be encrypted with keys that are not stored alongside them.

TLS 1.3 (IETF RFC 8446) is the right floor for transport. Machine-to-machine links between the record service and partner institutions, or between the service and on-premises adapters, should use mutual TLS so that both ends authenticate each other with certificates. The service should refuse to negotiate older protocol versions on any interface that carries Restricted or Personal fields, including internal interfaces between microservices; "it is inside the firewall" is not a control.

6.2.2 Authentication: people and machines

People should authenticate through the institution's identity provider with multi-factor authentication, and the record service should receive an access token rather than handling passwords itself. OAuth 2.0 (IETF RFC 6749) with OpenID Connect for identity is the usual combination. The PHASE-4 Annex J topology notes mention an OAuth 2.1 identity provider for multi-tenant gateways; OAuth 2.1 is still an IETF draft that consolidates current OAuth 2.0 best practice, so an implementation that follows the 2.0 security best-current-practice guidance is aligned with it in substance.

API keys have a narrower role. They are acceptable for identifying a registered client application, such as the HR import adapter, but they should not be the only credential for a caller that reads Restricted or Personal fields. For service accounts, prefer short-lived tokens obtained with client credentials over a static key, bind each service account to a single integration, and grant it only the scopes that integration needs. PHASE-4 also gives a rate limit of "1000 requests/hour"; that figure reads as template filler rather than an engineering requirement, and it is best treated as an example configuration value to be tuned per deployment.

6.2.3 Role matrix

RBAC is only as good as its role definitions. The matrix below is the book's proposed starting point for a university or hospital deployment. It uses six roles that correspond to real positions in biosafety governance and assigns access by record family. "Own" means limited to records of the caller's own laboratory or projects; "Summary" means the facility summary without Restricted fields; "Pseudonymous" means personnel identifiers are delivered as tokens that the caller cannot resolve.

Role	Facility summary	Location / access detail	Training records	Incident reports	Compliance results	Audit events
Biosafety officer	Read/write	Read/write	Read/write	Read/write, may resolve personnel IDs	Read/write	Read
IBC member	Read	Read, only for projects under review	Read, summary status only	Read, pseudonymous	Read	None
Principal investigator (PI)	Read	Read, own facilities	Read, own team	Create; read own lab, pseudonymous except own report	Read, own projects	None
Researcher	Summary	Own assigned room only	Read own	Create; read own reports	None	None
Inspector (external)	Read, time-boxed	Read, time-boxed and in scope	Read, in scope	Read, pseudonymous	Read	None
Auditor (internal/external)	Read	None by default	Read, sampled	Read, pseudonymous	Read	Read

Several design choices in the matrix deserve comment. The auditor is the only role besides the biosafety officer who reads audit events, and nobody can write or delete them; audit events are produced by the service itself (Chapter 5). The auditor does not by default see location detail, because verifying that a process works rarely requires knowing where a room is. The inspector role is time-boxed: access is granted for the inspection window with an explicit scope list and expires automatically, which is much safer than creating a permanent account and remembering to disable it. Researchers can always create incident and near-miss reports; making report creation the least-privileged action in the system is part of the non-punitive design discussed in Chapter 3.

Roles should be combined with attributes. A PI's "own facilities" is not a role but a relationship stored in the data (the facility's authorizedPersonnel list, project approvals), and the authorization layer must evaluate it at request time. This is sometimes called attribute-based access control layered on RBAC; in practice it means the policy engine needs read access to a small set of relationship data, not that every rule becomes a custom exception.

6.2.4 Audit logging of access, not only of changes

Chapter 5 defined the AuditEvent as a hash-chained record of changes. For Restricted and Personal fields, reads matter too. The service should emit an audit event whenever a caller retrieves location detail, resolves a pseudonymous personnel ID, or exports more than a single record. The WIA-BIO-017 error code B003 "Unauthorized access" (spec §9.4), mapped to HTTP 403 in Chapter 4, should always produce an audit event, and repeated B003 findings from the same account within a short window should notify the biosafety officer. These read-audit events are also what makes the inspector's time-boxed access reviewable after the fact.

6.3 Personal Data and Privacy

Biosafety records are full of personal data: names and staff numbers in training records, the list of people involved in an incident, the identity of whoever reported it, the names of assessors and reviewers. An institution operating in Korea must handle these under the Personal Information Protection Act (PIPA, 개인정보 보호법); one operating in or serving people in the European Union must also consider the General Data Protection Regulation (Regulation (EU) 2016/679, GDPR). Both laws favor data minimization, purpose limitation, security of processing, and privacy by design, and both treat health information as a specially protected category (PIPA's "sensitive information" and GDPR Article 9 special categories).

6.3.1 Reframing the "HIPAA/GDPR" line

PHASE-4 says implementations should ensure privacy "per HIPAA/GDPR". That line was written for clinical data. HIPAA is a US law that governs protected health information held by covered entities (such as health-care providers and health plans) and their business associates; a university's or company's employment and safety records are generally not what it was designed for, even when the institution also runs a hospital. For a biosafety record service, the more useful reading is: apply the institution's employee-data rules (PIPA or GDPR, plus local labor law) to training and incident records, and keep anything that is genuinely medical inside the occupational-health service, which has its own legal basis and confidentiality duties. Whether a particular institution falls under HIPAA, or under a specific Korean rule for workplace health data, is a question for its legal counsel, not for the software.

6.3.2 Separation of occupational-health data

The SDK's IncidentReport type has an optional medicalEvaluation field of type MedicalEvaluation. As Chapter 3 established, this book treats that type as out of scope and never embeds medical content in an incident record. The privacy argument is independent of the scope argument and reaches the same conclusion. If medical data lived inside the incident record, every role that can read the incident (the IBC, the PI, auditors, inspectors) would be one mistake away from reading health data they have no right to see, and every inter-institution exchange of incident statistics would need medical-grade handling.

The pattern is a reference, not a copy. The incident record holds an opaque case identifier issued by the occupational-health service and, at most, a status flag such as "referred" or "follow-up closed". The health service holds everything else in its own system. The biosafety officer can see that a referral exists and whether it is closed; only the health service can see why. Deployments should reject writes that populate medicalEvaluation at the API boundary, with a clear validation error, rather than relying on client software to leave it empty.

6.3.3 Pseudonymization of personnel in exchange

Within an institution, the biosafety office needs to know who was involved in an incident. Outside it, almost nobody does. Aggregated incident statistics sent to a national authority, near-miss lessons shared with a partner, and training-credential checks between institutions (Chapter 5) all work with pseudonymous identifiers. Pseudonymization replaces a direct identifier with a token that cannot be linked back to the person without additional information that is kept separately. Under GDPR Article 4(5) this is a defined term, and pseudonymized data remains personal data; PIPA likewise has a concept of pseudonymized information (가명정보) with its own processing conditions. Pseudonymization reduces risk but does not take the data out of the law.

A workable scheme uses a keyed hash (for example HMAC-SHA-256) of the internal personnel ID, with a separate secret key per exchange partner and per purpose. Per-partner keys mean two partners cannot join their data sets on the same token. Per-purpose keys mean that a token used in incident statistics cannot be matched to a token used in training verification. The keys stay with the sending institution's biosafety office; resolving a token back to a person is an audited action restricted to the biosafety officer role.

// Illustrative: per-partner, per-purpose pseudonymous personnel token
import { createHmac } from "node:crypto";

type Purpose = "incident-stats" | "training-verify";

function personnelToken(internalId: string, partnerId: string,
                        purpose: Purpose, keyFor: (p: string, u: Purpose) => Buffer): string {
  const mac = createHmac("sha256", keyFor(partnerId, purpose));
  mac.update(internalId);
  return "PSN-" + mac.digest("base64url").slice(0, 22);
}

Two caveats apply. First, a token is only as strong as the rest of the record: an incident report that names a small laboratory, a date, and a role such as "the only postdoctoral researcher in the group" identifies the person no matter how the ID is hashed. Quasi-identifiers must be generalized before exchange (the laboratory replaced by a department, the date by a month). Second, pseudonymization is not anonymization. For truly open publication, such as the WIA-SOCIAL sharing discussed in 6.5, records need to be reduced further until no individual can reasonably be singled out.

6.3.4 Retention and data-subject requests

Training and incident records may need to be kept for a period set by law or institutional policy, and Chapter 5 noted that retention is a jurisdictional decision. Privacy law adds the other side: data should not be kept longer than its purpose requires, and individuals may ask for access or correction. The record service should store a retention class on each record family, run a scheduled job that flags records past their retention date for review rather than deleting them automatically, and support an export of a person's own training records in a readable format. Deletion of an audited record should replace personal fields with a tombstone while keeping the audit chain intact, so that erasure does not break integrity verification.

6.4 Integration with the Existing Stack

No institution starts with an empty system. Training completions already live in an HR or learning-management system, door events in a physical access-control system, sample and material registries in a LIMS, inspection findings in an EHS platform, and SOPs in a document-management system. A WIA-BIO-017 record service succeeds when it becomes the place where these sources are reconciled into biosafety records, not when it asks staff to type everything in a second time.

6.4.1 Architecture

The recommended structure is an adapter layer between each source system and the record service. Each adapter owns one integration: it pulls or receives data from its source, maps it to WIA-BIO-017 types, validates it, and submits it through the same API that interactive clients use, with a service account scoped to that record family. The record service never reaches into source databases directly, and source systems never write into the record store directly.

  Source systems                Adapter layer                 Record service
  --------------                -------------                 --------------
  HR / LMS  ---- CSV/API ---->  training-adapter   --+
  Access control -- events -->  access-adapter     --+
  LIMS / registry -- IDs ---->  inventory-adapter  --+-->  WIA-BIO-017 API  -->  record store
  EHS platform -- findings -->  ehs-adapter        --+     (RBAC, field      (encrypted,
  Document mgmt -- SOP ver -->  sop-adapter        --+      projection,       hash-chained
                                                            audit events)     audit trail)
                                                                 |
                                                                 +-->  gateway (WIA-OMNI-API)  -->  partners

This shape has three benefits. Validation happens once, in the API, for every data source. Each adapter's service account can be revoked or rotated without touching the others. And the audit trail records which adapter produced each record, so a questionable training entry can be traced to the specific import batch that created it.

6.4.2 Source-system mapping

Source system	What it contributes	WIA-BIO-017 target	What stays in the source
HR / learning management	Course completions, assessment outcomes, certificate numbers	TrainingRecord	Course content, full HR file
Physical access control	Evidence that an access log exists and is retained; authorized-person lists	BiosaftyFacility.accessControls, authorizedPersonnel	Raw door events
LIMS / material registry	Institution-internal registry IDs and classification labels	Inventory references, custody records (Chapter 5)	Material characteristics
EHS platform	Inspection findings, corrective-action status	ComplianceResult, CAPA fields (Chapter 3)	Non-biosafety EHS data
Document management	SOP document ID and approved version	SOP reference fields on facility and incident records	SOP text

The last column matters as much as the others. The record service holds references and summaries, and the authoritative detail stays in the system that owns it. This limits what an attacker gains from compromising the record service, keeps the record service out of scope for data it has no business holding, and avoids two copies of an SOP drifting apart.

6.4.3 Access-control systems and the accessLog flag

The accessControls block in BiosaftyFacility contains booleans: restrictedAccess, selfClosingDoors, lockableDoors, accessLog, and an optional biometricAccess. It is easy to misread accessLog as a place to store door events. It is not; it asserts that an access log exists. That is the right design. Door events are high-volume, personal (they show where a named person was, and when), and already well protected in the physical-security system. Copying them into the biosafety record service would create a second, less specialized store of location-tracking data.

The access adapter should therefore do two narrow things. It should periodically confirm that the access-control system is producing and retaining a log for each registered facility, and set accessLog accordingly, with an audit event whenever the value changes. And it should reconcile the facility's authorizedPersonnel list against the badge-permission list in the access-control system, raising a compliance finding when a person holds door access but has no current authorization or training record. Answering "who entered room X on a given date" remains a query to the access-control system, performed by the people entitled to ask it.

6.4.4 Training import adapter

HR and learning systems export completions in their own format. The adapter below maps a hypothetical HR export row to a TrainingRecord. It uses a course catalog maintained by the biosafety office to map local course codes to the trainingType enumeration, and it returns the SDK's Result pattern so that a batch import can collect failures without stopping. Note that the course catalog, not the adapter, decides the refresher interval; as Chapter 2 explained, refresher cadence is institutional policy, and the adapter only copies the valid_until date that the HR system computed from that policy.

import type { TrainingRecord, Result } from "@wia/bio-017";

// Hypothetical row from an HR/LMS export (field names are the HR system's own)
interface HrTrainingRow {
  emp_no: string;
  display_name: string;
  course_code: string;
  completed_on: string;       // "2026-03-18"
  valid_until?: string;       // computed by HR from institutional policy
  assessed: "PASS" | "FAIL" | "";
  assessor_emp_no?: string;
  cert_no?: string;
}

type CourseEntry = { type: TrainingRecord["trainingType"]; topics: string[] };

interface AdapterError { row: string; reason: string }

export function toTrainingRecord(
  row: HrTrainingRow,
  catalog: Map<string, CourseEntry>,
  perIdOf: Map<string, string>          // employee number -> PER- ID (Chapter 2 mapping table)
): Result<TrainingRecord, AdapterError> {
  const course = catalog.get(row.course_code);
  if (!course) {
    return { success: false, error: { row: row.emp_no, reason: `unmapped course ${row.course_code}` } };
  }
  const trainingDate = new Date(row.completed_on + "T00:00:00Z");
  if (Number.isNaN(trainingDate.getTime())) {
    return { success: false, error: { row: row.emp_no, reason: "invalid completed_on" } };
  }
  const expirationDate = row.valid_until ? new Date(row.valid_until + "T00:00:00Z") : undefined;
  const personnelId = perIdOf.get(row.emp_no);
  const assessorId = row.assessor_emp_no ? perIdOf.get(row.assessor_emp_no) : undefined;
  if (!personnelId || (row.assessed !== "" && !assessorId)) {
    return { success: false, error: { row: row.emp_no, reason: "no PER- mapping for trainee or assessor" } };
  }

  const record: TrainingRecord = {
    personnelId,
    name: row.display_name,              // internal store only; dropped before any exchange
    trainingType: course.type,
    trainingDate,
    expirationDate,
    topicsCovered: course.topics,
    competencyAssessment: row.assessed === ""
      ? undefined
      : { passed: row.assessed === "PASS", assessor: assessorId! },
    certificationIssued: Boolean(row.cert_no),
    certificateNumber: row.cert_no || undefined,
    nextTrainingDue: expirationDate,
  };
  return { success: true, data: record };
}

A few details in this snippet carry policy. The personnel ID is never derived from the employee number. It is looked up in the Personnel mapping table of Chapter 2, so the PER- identifier stays pseudonymous and stable even when an employee number changes, and a row whose trainee or assessor has no mapping is rejected instead of receiving an invented ID. The person's display name is kept because the SDK type requires it, but the exchange layer of Chapter 5 strips it and substitutes the pseudonymous token of 6.3.3. The adapter does not invent a score: if the HR system records only pass or fail, score stays absent. And unmapped courses are rejected rather than guessed, which forces the biosafety office to decide explicitly whether a new course counts as biosafety training.

6.4.5 Document management and SOP versions

Incident investigations and inspections frequently ask which version of a procedure was in force at a given time. The record service should not store SOP text. It should store the document-management system's identifier and version number on the records where it matters: the facility registration (which SOPs apply to this facility), the incident report (which SOP version was current on the incident date), and CAPA actions (which revision a corrective action produced). The SOP adapter subscribes to approval events from the document-management system and updates the current-version references, emitting audit events so that the history is reconstructible.

6.5 WIA Ecosystem Hooks

The WIA-BIO-017 README lists four integrations with other WIA standards. WIA-BLOCKCHAIN, used for audit-trail anchoring, was covered in Chapter 5. The remaining three have privacy implications that should be settled before they are switched on. Each is described below with a scope note and a data-minimization rule. As with the illustrative endpoints elsewhere in this book, the availability of these services should be verified with the WIA Standards working group rather than assumed.

Integration	Role in the README	Scope note	Data-minimization rule
WIA-OMNI-API	Universal biosafety data gateway	Transport and routing for inter-institution exchange; not a data store	Only fields named in the exchange agreement pass the gateway; Restricted fields never do by default
WIA-INTENT	Intent-based laboratory safety queries	Natural-language or intent queries over records the caller may already see	Queries run under the caller's own token and field projection; no privileged service account
WIA-SOCIAL	Collaborative safety incident reporting	Sharing of de-identified near-miss lessons across institutions	Only a reviewed "lesson" record leaves; never the incident record itself

6.5.1 WIA-OMNI-API gateway

A gateway is attractive because it gives partners one integration point. It is also a place where data from many institutions passes, which makes it a target. The gateway should enforce, per partner relationship, an allow-list of record types and field paths agreed in the exchange agreement, and it should reject anything else even if the sending institution's service offers it. It should verify envelopes and signatures as described in Chapter 5 without needing to decrypt payloads where end-to-end encryption between institutions is used. Logging at the gateway should record envelope metadata (sender, receiver, record type, payload hash), not payload content.

6.5.2 WIA-INTENT query layer

Intent-based queries, such as "which people in my group have training that lapses this quarter", are genuinely useful to PIs and biosafety officers. The risk is architectural: if the query layer runs with a powerful service account and filters results afterwards, one flaw in the filter discloses everything. The rule is that the query layer acts as the caller, forwarding the caller's own token to the record API so that the same RBAC and field projection apply as to any other request. The query layer should also be confined to administrative questions about records. It is not a channel for generating technical safety guidance, a boundary that Chapter 8 discusses further.

6.5.3 WIA-SOCIAL anonymous near-miss sharing

Sharing near-miss lessons across institutions can help others avoid the same procedural gaps, and anonymity encourages people to share. The safe unit of sharing is a separate lesson record written for publication and reviewed by the biosafety officer before release. It is never the incident report with names removed. A lesson carries the incident type, a generalized setting (for example "teaching laboratory" rather than a room), the contributing administrative factors, and the corrective action that worked. It carries no dates finer than a month or quarter, no facility identifiers, no personnel tokens, and no material identifiers. Small institutions should be aware that even a generalized description can identify them to peers, and they may choose to publish through a consortium or with delay.

6.6 Pitfalls and a Redaction Checklist

Most privacy and security failures in record systems are not exotic. They come from collecting too much, exporting too much, and letting free text carry what the structured fields were designed to keep out. Three pitfalls are especially common in biosafety deployments.

6.6.1 Over-collection

It is tempting to capture everything a source system can provide "in case it is useful later". Every extra field is extra attack surface, extra privacy obligation, and extra content to review before an exchange. The integration mapping in 6.4.2 names what stays in the source for exactly this reason. The SDK's BiologicalAgent type is the clearest example: as Chapter 2 explained, a management record should hold an institution-internal registry ID and a classification label, not the characteristic fields that type provides for. A good test is to ask, for each field, which record-level question it answers for which role. If the answer is "none yet", the field does not belong in the schema.

6.6.2 Exporting facility floor-plan details

Floor plans, room layouts, and photographs of doors and equipment often find their way into facility registrations as attachments, because they were part of the paper application to the authority. They should not live in the record service, and they must never be included in an exchange or a report sent outside the biosafety office. Where a floor plan is needed for an inspection, share it through the authority's own channel or the document-management system under its own access control. Store only the document reference in the facility record.

6.6.3 Free-text leakage

Fields such as description, rootCause, immediateActions, and the lists of corrective and preventive actions are free text. They are where people naturally write what the structured fields deliberately omit: a colleague's name, a medical detail, the identity of a material, a room number. Structured pseudonymization is defeated by one sentence. Deployments should combine three measures: guidance and on-screen hints at the point of entry, an automated scan on save that flags likely personal names, staff numbers, room identifiers, and registry IDs for the author to review, and a mandatory human review of every free-text field before a record leaves the institution.

The checklist is deliberately phrased as questions a biosafety officer can answer without reading code. Items 1 to 6 can be enforced automatically by the exchange layer and the gateway; items 7 to 9 need a human, a log, or both. An implementation that automates the first six still benefits from printing the checklist on the export confirmation screen, because the person pressing the button is the last point at which a leaking sentence can be caught.

Summary

Biosafety record services concentrate information that is harmless piece by piece but sensitive when joined, together with personal data about researchers. The PHASE-4 controls (AES-256 at rest, TLS 1.3 in transit, RBAC with MFA, OAuth 2.0 with API keys, audit logging) are a sound baseline once they are made concrete: keys in a key-management service, mutual TLS between institutions, a role matrix with field-level projection, and audit events for sensitive reads as well as writes. Privacy design keeps medical data in the occupational-health service, pseudonymizes personnel with per-partner, per-purpose keys, and generalizes quasi-identifiers. Integration runs through one adapter per source system, with references stored and detail left where it belongs. The WIA-OMNI-API, WIA-INTENT, and WIA-SOCIAL hooks are each constrained by a data-minimization rule, and every export passes a redaction checklist that ends with a human reading the free text.