📝 Document systems access review

[JFWooten4]

They use this word "binder" a lot in the mock examinations staff principle discussions from #7. I don't see it in the actual Reg, but I think the principles behind it are sound and familiar. @JamesAlfonse was kind enough to share general notes/topics which could be covered and make sense to look over.

I will go through the judgment work in this PR of figuring out what can and shouldn't be made available. I'd like to lean towards disclosure, and it looks like a lot of these items will already be covered by the likes of #9, #11, and #14. Specifically, I think these issues already lay out a strong basis for publishing the data mappings for open-source hardening.

Data Map Hardening Ideation

Builds the definitions and data map for transfer-agent customer information and sensitive customer information under 17 CFR § 248.30(d). The work should define which natural-person securityholders, records, systems, vendors, files, exports, backups, and workflows are in scope for Regulation S-P safeguards, incident response, customer notice, service-provider oversight, disposal, and recordkeeping.

Recordkeeping implementation is out of scope for this PR and should be handled separately under the transfer-agent recordkeeping issue.

Regulatory basis

Subsection (d)(3): covered institution

Covered institution means any broker or dealer, any investment company, and any investment adviser or transfer agent registered with the Commission or another appropriate regulatory agency (“ARA”) as defined in section 3(a)(34)(B) of the Securities Exchange Act of 1934.

Subsection (d)(4): customer

Customer.

a. Customer has the same meaning as in § 248.3(j) unless the covered institution is a transfer agent registered with the Commission or another ARA.

b. With respect to a transfer agent registered with the Commission or another ARA, for purposes of this section, customer means any natural person who is a securityholder of an issuer for which the transfer agent acts or has acted as a transfer agent.

Subsection (d)(5)(ii): transfer-agent customer information

With respect to a transfer agent registered with the Commission or another ARA, customer information means any record containing nonpublic personal information as defined in § 248.3(t) identified with any natural person, who is a securityholder of an issuer for which the transfer agent acts or has acted as transfer agent, that is in the possession of a transfer agent or that is handled or maintained by the transfer agent or on its behalf, regardless of whether such information pertains to individuals with whom the transfer agent has a customer relationship, or pertains to the customers of other financial institutions and has been provided to the transfer agent.

Subsection (d)(6): customer information systems

Customer information systems means the information resources owned or used by a covered institution, including physical or virtual infrastructure controlled by such information resources, or components thereof, organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of customer information to maintain or support the covered institution's operations.

Subsection (d)(9): sensitive customer information

Sensitive customer information means any component of customer information alone or in conjunction with any other information, the compromise of which could create a reasonably likely risk of substantial harm or inconvenience to an individual identified with the information.

Examples of sensitive customer information include:

a. Customer information uniquely identified with an individual that has a reasonably likely use as a means of authenticating the individual's identity, including:

a. A Social Security number, official State- or government-issued driver's license or identification number, alien registration number, government passport number, employer or taxpayer identification number;

b. A biometric record;

c. A unique electronic identification number, address, or routing code;

d. Telecommunication identifying information or access device (as defined in 18 U.S.C. 1029(e)); or

b. Customer information identifying an individual or the individual's account, including the individual's account number, name or online user name, in combination with authenticating information such as information described in paragraph (d)(9)(ii)(A) of this section, or in combination with similar information that could be used to gain access to the customer's account such as an access code, a credit card expiration date, a partial Social Security number, a security code, a security question and answer identified with the individual or the individual's account, or the individual's date of birth, place of birth, or mother's maiden name.

Subsection (d)(10): service provider

Service provider means any person or entity that receives, maintains, processes, or otherwise is permitted access to customer information through its provision of services directly to a covered institution.

Subsection (d)(11): transfer agent

Transfer agent has the same meaning as in section 3(a)(25) of the Securities Exchange Act of 1934 (15 U.S.C. 78c(a)(25)).

Subsection (a)(3)(i): incident assessment dependency

Assess the nature and scope of any incident involving unauthorized access to or use of customer information and identify the customer information systems and types of customer information that may have been accessed or used without authorization;

Changes to be made

• Create a Regulation S-P definitions page for transfer-agent customer information and sensitive customer information.
• Define the natural-person securityholders that count as customers for transfer-agent purposes.
• Identify issuers for which BlockTransfer acts or has acted as transfer agent.
• Map customer information by record type, system, vendor, storage location, workflow, and responsible owner.
• Identify which records contain nonpublic personal information tied to natural-person securityholders.
• Classify sensitive customer information using the categories in Subsection (d)(9).
• Identify customer information systems used to collect, process, maintain, use, share, disseminate, or dispose of customer information.
• Identify service providers that receive, maintain, process, or otherwise have access to customer information.
• Map exports, backups, email attachments, shared folders, cloud storage, API systems, issuer files, and operational tools that may contain customer information.
• Define how the data map supports incident assessment, affected-individual identification, customer notice decisions, service-provider oversight, disposal, and recordkeeping.
• Cross-reference the safeguards, incident response, assessment, customer notice, service-provider oversight, disposal, and transfer-agent recordkeeping workstreams.

[JFWooten4]

If you end up doing a bunch of deduplication changes on this or recommendation edits on their bits, I can definitely extend repo write access too, to streamline collab these next weeks at a minimum.

The geoblocking from known adversarial countries makes a ton of sense. Never even thought to do that in the portal because of the additional auth methods.

[JamesAlfonse]

Not sure if I submitted my pull request in the right area, but here it is: #43 (commits)

[JamesAlfonse]

Additionally, see below for a possible starting point of an audit-readiness gap analysis.

The idea would be to compare BlockTransfer’s current security posture against the controls likely needed for SOC 1 Type II readiness, with SOC 2 Type II and Reg S-P as supporting considerations.

---

Recommended Audit Path for BlockTransfer

For BlockTransfer, the first audit objective should be:

SOC 1 Type II first — then SOC 2 Type II

BlockTransfer appears to operate as transfer-agent infrastructure for securities transfer, recordkeeping, compliance automation, issuer and investor workflows, and digital stock certificate management.

Because of that, the best first audit is SOC 1 Type II, not ISO 27001 and not SOC 2.

Why SOC 1 Type II First

Transfer agents are responsible for maintaining issuer securityholder records, recording ownership changes, issuing and canceling certificates, and supporting core securities administration workflows.

For BlockTransfer, the most important trust question is:

Can issuers, auditors, boards, and financial institutions rely on BlockTransfer’s shareholder recordkeeping and transfer-processing controls?

That is a SOC 1 Type II question.

A SOC 1 report is designed for controls at a service organization that may affect a customer’s internal control over financial reporting. For a transfer agent, that maps directly to controls around:

• accuracy of shareholder records;
• authorization of transfers;
• issuance and cancellation of certificates;
• reconciliation between on-chain and off-chain records;
• access controls over the official shareholder register;
• transaction processing completeness and accuracy;
• audit trails;
• change management for registry or ledger logic;
• backup, recovery, and incident response for the securityholder file.

Why Not SOC 2 First?

SOC 2 Type II is still important, especially because BlockTransfer handles sensitive investor data and digital infrastructure.

SOC 2 focuses on controls related to:

• security;
• availability;
• processing integrity;
• confidentiality;
• privacy.

However, for a transfer agent, the first issue is not only whether the platform is secure. The first issue is whether the company’s recordkeeping and transfer-processing controls can be relied on by issuers and their auditors.

That makes SOC 1 Type II the better first audit artifact.

Why Not ISO 27001 First?

ISO 27001 is useful as a broad information-security management certification, especially for enterprise credibility and international trust.

However, ISO 27001 is less directly tied to transfer-agent recordkeeping, issuer financial reporting, and auditor reliance. It does not answer the core transfer-agent control question as directly as SOC 1 Type II.

ISO 27001 is better as a later-stage certification after the security program is mature.

Reg S-P Readiness

Separately from audit certifications, BlockTransfer should prepare for SEC Regulation S-P obligations.

Reg S-P readiness should influence the SOC 1 and SOC 2 control environment, especially around:

• safeguarding sensitive investor information;
• access controls;
• incident response;
• breach notification workflows;
• written policies and procedures;
• evidence retention;
• vendor and third-party risk management.

Reg S-P is not a certification, but it is highly relevant to the control environment BlockTransfer will need to demonstrate.

Recommended Sequence

First: SOC 1 Type II

Scope the SOC 1 Type II around transfer-agent operations and digital certificate/shareholder-record controls, including:

• shareholder registry accuracy;
• transfer authorization;
• certificate issuance and cancellation;
• transaction completeness and accuracy;
• reconciliation between blockchain-based and traditional records;
• privileged access controls;
• change management;
• audit logging;
• backup and recovery;
• incident response for registry-impacting events.

Second: SOC 2 Type II

Scope the SOC 2 Type II around platform security and data protection, including:

• cloud infrastructure;
• API security;
• identity and access management;
• key management;
• encryption;
• monitoring and logging;
• availability;
• confidentiality;
• privacy;
• incident response;
• vulnerability management;
• vendor management.

Later: ISO 27001

Pursue ISO 27001 once the security program is mature enough that certification will be efficient and sustainable.

ISO 27001 can help demonstrate a formal information-security management system, but it should come after the audit artifacts that most directly support issuer, auditor, and financial-institution due diligence.

Bottom Line

BlockTransfer should pursue SOC 1 Type II first.

SOC 1 Type II best aligns with BlockTransfer’s role as a transfer agent responsible for shareholder records, digital stock certificate controls, transfer processing, and issuer-facing financial-record reliability.

After that, BlockTransfer should pursue SOC 2 Type II for security and data-protection assurance, followed by ISO 27001 if broader enterprise or international certification becomes useful.

[JamesAlfonse]

Building on the audit-readiness recommendation above, the next practical step is to turn that recommendation into a gap analysis.

The goal would be to compare BlockTransfer’s current security and operational controls against the controls likely needed for SOC 1 Type II readiness, while also identifying where the same work supports SOC 2 Type II and Reg S-P readiness.

This is not intended to be a final audit scope, but a starting structure for identifying gaps, owners, evidence, and remediation priorities.

---

BlockTransfer Audit Readiness Gap Analysis

1. Governance and Scope

Assess whether BlockTransfer has clearly defined:

• transfer-agent services in scope;
• systems that maintain shareholder records;
• systems that issue, cancel, or update digital stock certificates;
• blockchain/off-chain reconciliation processes;
• third-party systems and vendors;
• control owners;
• audit evidence owners.

Example gap questions:

• Is there a documented system boundary for transfer-agent operations?
• Are issuer-facing responsibilities clearly separated from platform/security responsibilities?
• Is there a current control matrix?
• Are control owners assigned?

---

2. Shareholder Recordkeeping Controls

Assess whether controls exist for the accuracy, completeness, and integrity of shareholder records.

Review:

• shareholder registry updates;
• ownership changes;
• certificate issuance;
• certificate cancellation;
• transfer approvals;
• exception handling;
• manual overrides;
• audit trails.

Example gap questions:

• Is every shareholder record change traceable to an approved request?
• Are changes logged with user, timestamp, before/after state, and reason?
• Are certificate issuance and cancellation workflows documented?
• Are manual changes independently reviewed?

---

3. Transfer Authorization Controls

Assess whether transfers are properly authorized before execution.

Review:

• identity verification;
• issuer approval requirements;
• investor authorization;
• restricted securities workflows;
• approval thresholds;
• segregation of duties;
• rejected or failed transfer handling.

Example gap questions:

• What prevents an unauthorized transfer?
• Are approvals captured before registry updates occur?
• Can one user both approve and execute a transfer?
• Are transfer exceptions reviewed?

---

4. Reconciliation Controls

Assess whether BlockTransfer can reconcile digital certificate records, blockchain records, and official shareholder records.

Review:

• reconciliation frequency;
• reconciliation ownership;
• exception reports;
• unresolved breaks;
• on-chain/off-chain matching logic;
• evidence retention.

Example gap questions:

• Is there a formal reconciliation process?
• Are reconciliation exceptions tracked to resolution?
• Is reconciliation evidence retained?
• Are blockchain records reconciled against the official books and records?

---

5. Access Controls

Assess whether access to transfer-agent systems is restricted, approved, reviewed, and removed when no longer needed.

Review:

• admin access;
• issuer access;
• employee access;
• service accounts;
• API access;
• privileged access;
• cross-account access;
• MFA;
• access reviews.

Example gap questions:

• Who can alter shareholder records?
• Who can issue or cancel certificates?
• Who can change permissions?
• Are access reviews performed on a recurring cadence?
• Are terminated users removed promptly?

---

6. Credential and Key Management

Assess whether credentials and keys are inventoried, protected, rotated, and monitored.

Review:

• API keys;
• access keys;
• service account credentials;
• blockchain signing keys, if applicable;
• encryption keys;
• emergency access credentials;
• key rotation;
• stale credentials.

Example gap questions:

• Are all keys and credentials inventoried?
• Are keys assigned to owners?
• Are credentials rotated on schedule?
• Are stale credentials removed?
• Are signing keys protected with appropriate controls?

---

7. Change Management

Assess whether changes to transfer-agent systems are authorized, tested, approved, and traceable.

Review:

• application changes;
• smart-contract or ledger logic changes, if applicable;
• database changes;
• infrastructure changes;
• emergency changes;
• rollback procedures;
• deployment approvals.

Example gap questions:

• Are production changes approved before deployment?
• Are changes tested before release?
• Is there evidence of approval and testing?
• Are emergency changes reviewed after the fact?
• Can developers directly modify production records?

---

8. Logging and Monitoring

Assess whether BlockTransfer can detect misuse, unauthorized changes, and suspicious access.

Review:

• access logs;
• admin activity logs;
• shareholder-record change logs;
• API logs;
• certificate issuance/cancellation logs;
• failed login logs;
• alerting;
• log retention;
• log integrity.

Example gap questions:

• Are critical actions logged?
• Are logs protected from alteration?
• Who reviews logs?
• How are suspicious events escalated?
• Are logs retained long enough for investigations?

---

9. Incident Response

Assess whether incident response procedures address transfer-agent-specific compromise scenarios.

Review:

• compromised admin account;
• compromised service account;
• exposed API key;
• unauthorized shareholder-record change;
• certificate issuance error;
• blockchain/off-chain reconciliation failure;
• data breach involving investor information;
• issuer notification workflows;
• regulator or legal escalation.

Example gap questions:

• Is there an incident response plan?
• Does it cover transfer-agent record integrity incidents?
• Are roles and escalation paths documented?
• Are tabletop exercises performed?
• Is evidence preserved for investigations?

---

10. Backup, Recovery, and Business Continuity

Assess whether BlockTransfer can recover critical transfer-agent records and operations.

Review:

• registry backups;
• database backups;
• certificate records;
• recovery procedures;
• restoration testing;
• recovery time objectives;
• recovery point objectives;
• dependency mapping.

Example gap questions:

• Are shareholder records backed up?
• Are backups tested?
• Can BlockTransfer restore the official register after corruption or compromise?
• Are recovery procedures documented?
• Are critical vendors included in continuity planning?

---

11. Privacy and Reg S-P Readiness

Assess whether investor information is protected and whether breach response workflows are documented.

Review:

• sensitive investor information;
• privacy policies;
• access restrictions;
• encryption;
• vendor access;
• incident notification procedures;
• evidence retention;
• written policies and procedures.

Example gap questions:

• What sensitive investor information does BlockTransfer collect?
• Who can access it?
• Is it encrypted in transit and at rest?
• Are breach notification workflows documented?
• Are third-party vendors reviewed for data protection?

---

12. Vendor and Third-Party Risk

Assess whether vendors supporting transfer-agent operations are identified, reviewed, and monitored.

Review:

• cloud providers;
• blockchain infrastructure providers;
• identity providers;
• payment or banking partners;
• monitoring/logging tools;
• customer-support tools;
• outsourced development or operations.

Example gap questions:

• Which vendors support critical transfer-agent functions?
• Are vendor risks reviewed before onboarding?
• Are vendor SOC reports collected where applicable?
• Are vendors monitored periodically?
• Are vendor incidents escalated into BlockTransfer’s incident response process?

---

Gap Analysis Output

For each control area, document:

Field	Description
Control Area	Example: Access Controls
Expected Control	What should exist
Current State	What exists today
Gap	What is missing or weak
Risk	Why the gap matters
Priority	High / Medium / Low
Owner	Person responsible for remediation
Remediation Plan	What needs to be done
Evidence Needed	Artifact needed for audit readiness
Target Date	Planned completion date
Status	Open / In Progress / Complete / Accepted Risk

Example Gap Entry

Field	Example
Control Area	Reconciliation Controls
Expected Control	Digital certificate records are reconciled to the official shareholder register on a defined cadence.
Current State	Reconciliation is performed manually but not consistently documented.
Gap	No formal reconciliation procedure, evidence retention standard, or exception-resolution workflow.
Risk	Inaccurate ownership records may go undetected, affecting issuer reporting and transfer-agent reliability.
Priority	High
Owner	Operations / Engineering
Remediation Plan	Define reconciliation procedure, assign owner, create exception log, retain evidence for each review.
Evidence Needed	Reconciliation policy, completed reconciliation samples, exception log, reviewer sign-off.
Target Date	TBD
Status	Open

Recommended First Step

Start with a SOC 1 Type II readiness gap analysis focused on:

1. shareholder recordkeeping;
2. transfer authorization;
3. certificate issuance and cancellation;
4. reconciliation;
5. privileged access;
6. change management;
7. logging and monitoring;
8. backup and recovery;
9. incident response;
10. evidence retention.

Then map overlapping controls to SOC 2 Type II and Reg S-P so the same remediation work can support future audits and compliance readiness.

[JamesAlfonse]

If you end up doing a bunch of deduplication changes on this or recommendation edits on their bits, I can definitely extend repo write access too, to streamline collab these next weeks at a minimum.

The geoblocking from known adversarial countries makes a ton of sense. Never even thought to do that in the portal because of the additional auth methods.

No need for repo write access right now, pull requests are easy enough. Will let you know if that changes.

As for geoblocking: not only can it reduce intrusion attempts, but it can also reduce unnecessary logging noise (and potentially logging costs!) :)

[JFWooten4]

Thanks so much for really fleshing these remarks out here, James! 🎉 I'm going through the full lists and processes as I move as much as possible directly onto GitHub in #44 for #20.

The SOC ideas are interesting because they're actually not required by the regulation as written. I always saw the process as overly centralized and symptomatic of too much intermediary trust.

Namely, for the SOC 1 Type II ideas, I'm pretty far along in moving most of our financials on-chain, which should make things a lot more transparent. I'd say progress is about in step and pace with the DUNA wallet setup.

That said, and notwithstanding, I am all for more help making sure our accounts are right, as was suggested by Bob in the AGM. The only thing I'd ask right now is whether the cost of audit help is worth the payoff at the moment.

For "shareholder recordkeeping and transfer-processing controls" which are largely open-source, we have the good fortune of SEC Examiners who review our securityholder records, ownership issuance, and "core securities administration workflows" on the U.S. taxpayer's dime.

They particularly found some deviance with "reconciliation between on-chain and off-chain records" in the exam last year, so I agree completely that these are things we should inspect. Whether or not it needs to be an explicit outside report v. community looking around and asking questions is the only bit I deviate on.

Lastly, I agree that we need to do a lot of work on audit trails, which I'm starting in the CRON-jobs repo. That will be a substantial bit of the setup and ongoing work scanning cloud logs for intrusions.

So maybe set that up, and then we'd be in a better place for some outside consult. I'd also like to have a more mature Stellar multisig setup for "access controls over the official shareholder register" which is all on-chain.

[JFWooten4]

For the gap analysis, this might not be the right format. But I mean the questions here asked, and I'd like to make things clear. Maybe by spelling some of this out, it'll be easier to write the upcoming policy docs.

1. Governance and Scope

For most of the highlighted bullet points, I'd say the logic and explanations actually lie in the TAD3-docs repo, aside from vendors and audits, since everything is native Stellar. I am not entirely sure what a boundary or scope would be for operations, except that we define the explicit issuer agreements for service based on the TAD3-protocol repo drafting.

There aren't a ton of issuer-facing responsibilities I can think of aside from onboarding and letting their investors know who their agent is. There is the separate item of issuer insider management, but that falls under the issuer disclosure docs and authentication.

For the questions around a control matrix and owners, I have started scoping out what hopefully will be a visually appealing risk register. But I functionally disagree with the control framing and owner model, since that implies directive work and goes against what I see as the open-source ethos of anyone being able to work on anything.

2. Shareholder Recordkeeping Controls

This is the one section I'd defer most to the Commission as an examining body, since they are really the only auditor I'd trust for certainty on accounting numbers. The biggest slips that need oversight come from onboarding migration from the legacy shareholder registry, since that should be the only time when a BT team member has to work with data.

Right now there is a clear audit trail of who in the company assisted with what migration. That's built into the Dynamo workflows from the py-TAD3-horizon repo, but I would rather, looking forward, that it be more tightly integrated into issuers.info so that the company can self-migrate and define their own preexisting custom restrictions.

As for the bullets on the register and ownership changes, those are all on-chain with noncustodial wallets once the users and assets are onboarded, so I wouldn't have much qualm there. It only gets interesting when you start monitoring trading.

Certificates are a big, icky problem I've been grappling with for a long time, and I don't have a perfect answer for that at the moment. I will need to formalize the process for that in the next two weeks as I make the final call on at least the secretarial design, which will manifest in the TAD protocol item.

The exception handling routes through nonroutine item processing, which is a really heavily regulated function. We haven't had any of those yet, so the workflows around them are admittedly pretty immature.

Not to sound like a dead horse, but again that would ideally work through a tighter issuers.info integration. I discussed it with staff last year, and they echoed that design direction to minimize manual human involvement.

For change logs, all the code will sync from GitHub, the PII databases have recurrent backups set based on the exam, and actual transactions like shareholder records are all on Stellar for maximum traceability. The only thing on the top of my mind is we don't have a reliable way to update your investor information yet, and the associated logging of signatures for that, since it has been by email in the Incumbent beta period without an actual investor app.

There are no certificate issuance processes right now, but the cancellation workflows will be documented in #15. I have the tooling in place for it virtually and physically, but it doesn't scale perfectly yet since the paper gets complicated.

And for the last point, ideally there are no manual changes. I had to make some for Layerlo, and I'd rather something like that outside the Lambda functions from syndicate-api generate an alert of abnormal modification as an incident notice.

3. Transfer Authorization Controls

Identity verification is a whole WIP repo right now as we open-source the KYC. I suspect we'd develop some more advanced investor authentication workflows as that plugin improves for the app.

Right now there are not hard issuer approval requirements, as I've discussed a few times in the DRS community. I've used my judgment to allow use by companies that are not obvious scams, and if we want something more nuanced than that, then I would recommend a draft in TAD3-protocol, which would lead to a more nuanced discussion of company governance.

For restricted securities, aside from the manual offline arrangements discussed, the stack mostly relies on Rule 144. I haven't gotten around to writing in 144A or the QIB exemptions because I don't really respect those forms of asset allocation.

144 is a cornerstone of the protocol, which is thoroughly discussed in the exam and TAD3 docs as really the only specific citation right now. It's pretty straightforward based on time held and affiliation, which is built deeply into the issuers.info API for the company classification branch imported to the Python interface.

I am not sure what segregation of duties would refer to, but there are existing website user terms covering failed transfers under the signature guarantee policy. Basically the logic is that a failed blockchain transaction will be known immediately to the user, and they can remedy whatever caused their transfer to fail or know immediately why if there is a hold data value in their investor profile for something like an affiliation.

Most of the transfer questions are easily answered by evidence of signatures and processing on Stellar, with the exception of the distributor processing when you move from a certificate or Cede position. That uses a pretty centralized internal function as a team member manages the position migration from the omnibus bulk account to the user wallet.

For the latter challenge, I am getting to a good position of having the CCP use their own wallet like other corporate investors. Interestingly, they aren't directly covered as a trustee by the letter of the natural-person protections in S-P.

If you can offload the wallet signing with external approvals from the issuer for legacy DRS, DTC, or a paper guarantor, then there's much less trust implicit in our corporate operations. Because right now there is one user (me) who both approves and executes a migration transfer, with nobody to review that aside from the SEC.

4. Reconciliation Controls

Most of the blockchain reconciliation is done under the Py caching functions or will be done in the CRON jobs. There are two caching Dynamos right now, but I think we'll need to refactor that system with the deprecation of Horizon support.

Legacy-wise, we will likely need to start running our own nodes since the Stellar RPC doesn't nicely display order and offer IDs. I plan to write a no-action letter for that through the DUNA, with a backup option through the community service validator providers.

So, the exception reports are part of the nonroutine item processing or would have some kind of substantial issuer documentation accompanying them, as exemplified and implemented by referencing the hashes of their decisions in transaction meta during the beta. I would like to make these ports into AWS so we have a single secure repository, and backup processes with the records custodian, that links directly to the issuer disclosure submissions and migrations, which are largely through Lambda for onboarding.

Then all that can be retained and cited as part of the Ad-6 recordkeeping requirements. As for reconciliation, the blockchain records are the official books and records.

5. Access Controls

The workflows here are pretty immature as well since I have been the only one handling access to production data. I'm working on open-sourcing the IAMs as we speak so that it can be easier to see what's happening, but I know there's a lot more to think about when it comes to adding new team members without directing their edit actions.¹

Accordingly, there's not much worth discussing in terms of team access policies at the moment, save for the independent subaccounts, which isolate tokenized PII that is especially sensitive. That is being documented in blocktransfer/CRON-jobs#7

In my mind, issuers have no access to any of these systems. There's just the mTLS connection.

All of my access points use MFA, and I have it enabled for the GitHub teams. I'd like to make this much more clear with the logging work to be done here so that a public review stream can emerge from a clear endpoint.

Terminated users are not removed since the statutory retention period goes on for many years. I was thinking about how to add longstanding TTLs to all their data, but that's a larger question which affects

6. Credential and Key Management

Right now the API keys are remitted by IAM to SSO identities. They are exported manually in the SSO AWS console with up to about an 8-hour TTL.

Aside from that are longstanding member credentials for the likes of GitHub or even our communication platforms like Discord. There's nothing for external service providers aside from the legacy Persona instance on the deprecated Zoho beta site, which is far out of production.

Access keys, aside from the cloud service providers, are important in view of the blockchain signing keys. This is the most tangible, viewable aspect of security, which is scoped out in the #41 note.

Right now we use the default AWS KMS encryption keys, which rely on the IAM access credential to get into their managed environment. S-P carves out a safeguard for encryption at rest, but I haven't expanded into managing our own content keys at this time.

I have minimal to no credential rotation in place for ease and also to force reliance on 2FA, which I think should be the only point of reliance anyway. Automated Stellar key rotation, which is possible in Secrets Manager routines, also relies on long-term keys for the sake of not having high-threshold signing pairs in the client, which you'd need to update the keys.

Perhaps these docs can inventory all the credentials in a central place rather than just my head, which would make it easier to check when they were last updated. For the wallets, like I said, I'd rather have account IDs of team members resolve to their wallets and then act as a signing participant with low individual weight.

7. Change Management

Changes to TAD3 will be bureaucratic to implement. It should be clear exactly how database or infrastructure changes happen on GitHub.

I do not have any procedures in place for emergency changes other than freezing all the asset holders for a stock. After that you can also use clawbacks to roll back any illicit changes.

I still need to configure the IAM CRONs and link Lambda to GitHub, but in principle all deployment approvals would come from PR reviews. Once branches merge into main, they sync into AWS, so it needs the same protections of write-access team members as with the stellar.toml file we discussed with the Commission.

Our repos don't have many test cases right now. So, to help this point, different projects should eventually implement unit testing.

8. Logging and Monitoring

Definitely need logging for the team. The IssuerLink design considers it for users.

I put a lot of faith in the public keys as signing authenticators that obviate much of this. The user can only access their account with an initial seed phrase, which puts opsec far above most presuming paper key storage.

9. Incident Response

Unauthorized shareholder-record change will definitely be a big one to consider in the logging. I will also need to frame out the certificate processing so that it's more digital and thus easier to track and oversee.

There should never be a reconciliation failure between on- and off-chain records. That is to be guaranteed by blocktransfer/syndicate-api#3

Interestingly, the statute only requires notice to investors, and broadly that would include insiders at the issuer. I can't imagine the breach would be limited to only one class of security holders, since all PII coalesces into the database so that you can hold any TAD security.

And then there is no defined escalation path to tell regulators about breaches. And legal remediation would largely depend on state laws, which don't have much you can do to preempt other than build good policy here.

The questions reference record integrity, but that should really be an operational / TAD3 compliance oversight question for the team. The only breach surface I can think of would be editing your balance in the legacy shareholding database, which should be detected by the API change and is worth further logging work.

10. Backup, Recovery, and Business Continuity

There are more substantial internal continuity and recovery processes referenced in #35. That's one of, if not the only, bits of policy work I'm yet to open-source because it deals with the physical security and logistics of the master signing keys.

Once we have the multisig set up, then it should be a lot easier to make this more community-centered. We will get to start that implementation with the DUNA treasury soon.

Right now we have PITR recoveries made manually in Dynamo. The upcoming CRONs will automate that to daily backups, which can then be checked into data histories for issuer review.

As for the share ledger, the blockchain itself is the ultimate history for ownership recovery once onboarded. I have open-source tools for ledger reconstruction at a specific timestamp if you can't find a snapshot.

I haven't needed to test the backups yet. From my visual examination of their duplicated contents, it should be a simple drop-in on the Console UI should we need them.

The official register is a combination of PII and blockchain queries. The former is through AWS, who I haven't included in continuity planning since that's the role of #19, though I am reaching out to them as an alternate #22 recordkeeper.

11. Privacy and Reg S-P Readiness

We collect shareholder names, addresses, birthdates, and more spelled out here. There actually is a defined federal scope of investor information, so it's mostly interpretive of what will serve issuers and account recovery.

Issuers can access a subset of this information when they generate shareholders lists, view aggregate investor info, and other pending functions in IssuerLink. And again it uses the default AWS encryption keys (symmetric).

12. Vendor and Third-Party Risk

I'm working on this in #12. There are no entities right now that provide blockchain infrastructure or identity workflows in prod.

There are basic banking systems for the minimal centralized treasury, but they are inadequate for TA operations and not a vendor in my view. I wanted Bury to step up and handle some of this back in 2024 on, but now things are steering closer to a stablecoin servicer who will need to get vetted.

There aren't any independent logging tools right now, and I'm trying to deprecate the old Zoho support tooling. It is still up in the air how much internal support team members we'll need as we build out the support portal wireframes.

AWS has plenty of SOC and audit reports in Artifact that demonstrate cloud responsibility and compliance with industry standards. And for the blockchain systems, you can look at their total value securely stored as a proxy for hack integrity.

I'm very selective with vendors because of my high quality standards. After June 3 they will all need to go through the more complete performance needs.

These include periodically monitoring vendors as in the policy doc. They need to provide notice within 3 days of incidents, which are then escalated into the incident response program via issues.

Footnotes

1. I've looked to the Free Law Project for some inspiration on this matter. They have a central database of "secure" records from the public legal system which only select open-source contributors can access. ↩