📝 Document systems access review

_category_ copy.json

@@ -0,0 +1,6 @@
+{
+  "label": "operationss-ish"
+}
+commti combining finincails with taxes
+
+onbeanigng beta to legacy static

_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Compliance Manual"
+}
+not forall

incidents/README.md

@@ -1 +1,79 @@
-# Regulation S-P
+## Cloud access inventory and review
+
+Create a private inventory and public tracking issue for AWS/cloud access governance without exposing sensitive account details.
+
+The goal is to make sure the project knows which cloud accounts, identities, credentials, and permissions exist; who owns them; whether they are still needed; and how they would affect incident detection, investigation, containment, and recovery.
+
+### Inventory scope
+
+- [ ] Inventory all cloud accounts and identities currently in use, including AWS accounts, human users, service accounts, console access, API access, and cross-account access.
+- [ ] Inventory all credentials and access paths, including API keys, access keys, tokens, long-lived credentials, and temporary or session-based access.
+- [ ] Inventory all accounts that can access protected data.
+- [ ] Inventory all non-human and automation access, including CRON jobs, automated workflows, deployment systems, monitoring, logging, alerting systems, and third-party services.
+- [ ] Inventory all backup, archival, or recovery access paths.
+- [ ] Store the sensitive inventory in a private operational record.
+
+### Admin account review
+
+- [ ] Identify all admin accounts.
+- [ ] Treat any account that can create accounts, grant permissions, or rotate credentials as an admin account.
+- [ ] Treat any account that can access protected data as requiring elevated review.
+- [ ] For each admin account, document the owner, business purpose, and whether the access is still needed.
+- [ ] Remove or reduce unnecessary admin access.
+- [ ] Confirm that admin accounts use MFA.
+- [ ] Confirm that root or owner-level accounts are separately protected.
+
+### Credential review
+
+- [ ] Record the last rotation or review date for each credential.
+- [ ] Record whether each credential is still active.
+- [ ] Confirm each credential has a known owner.
+- [ ] Confirm each credential has a documented business purpose.
+- [ ] Confirm each credential has least-privilege permissions.
+- [ ] Identify stale, unused, or unnecessary credentials.
+- [ ] Remove stale or unused credentials.
+- [ ] Rotate credentials that are overdue.
+- [ ] Establish a recurring credential rotation and review cadence.
+
+### Access-policy review
+
+- [ ] Review each account’s effective permissions.
+- [ ] Review what protected data each account can reach.
+- [ ] Review whether access is read-only or write-capable.
+- [ ] Review whether permissions match the current operational need.
+- [ ] Review whether any account can alter security-critical controls, including logs, monitoring, or security settings.
+- [ ] Review whether any account can manage identities or credentials, including users, service accounts, and API keys.
+- [ ] Review whether any account can assume roles across accounts.
+- [ ] Review whether any public or shared credentials exist.
+- [ ] Remove or reduce permissions that are broader than needed.
+
+### Incident response connection
+
+- [ ] Map accounts to the incident response program.
+- [ ] Identify which accounts could be involved in detecting, investigating, containing, or recovering from breaches.
+- [ ] Identify which accounts could affect protected data during an incident.
+- [ ] Document the logs needed to detect misuse of each account.
+- [ ] Identify where access logs are stored.
+- [ ] Identify who reviews access logs.
+- [ ] Identify how suspicious access is escalated.
+- [ ] Document response procedures for compromised admin accounts, service accounts, and exposed API keys.
+- [ ] Confirm that incident responders know where the private access inventory is stored.
+
+### Review cadence
+
+- [ ] Establish recurring review cadences for accounts, admin access, service accounts, credentials, cross-account access, and protected-data access.
+- [ ] Document when each review occurs.
+- [ ] Document who performed each review.
+- [ ] Document what changed after each review.
+- [ ] Document any unresolved findings.
+- [ ] Track unresolved findings until they are resolved, accepted, or assigned a follow-up owner.
+
+### Public issue safety
+
+- [ ] Do not publish sensitive identity details, including usernames, privileged-account emails, or account names that create security risk.
+- [ ] Do not publish secrets or credential details, including API keys, access keys, tokens, passwords, or password-history details.
+- [ ] Do not publish detailed permission maps if they would help an attacker.
+- [ ] Publicly document that the private inventory exists.
+- [ ] Publicly document that the inventory is reviewed on an appropriate cadence.
+- [ ] Keep the sensitive inventory in a private operational record.
+- [ ] Keep the public issue focused on policy, cadence, and evidence of review.

incidents/SECTIONS.md

@@ -0,0 +1,34 @@
+# ORGANIZATION final as README
+
+- Risk registry
+  - Control assessments
+  - Technology assessments
+  - Cybersecurity assessments
+- Vulnerability management
+  - TAD surfaces
+  - Stellar surfaces
+  - Deployment vulnerabilities
+- Key management
+  - Technical administration, provisioning
+  - Physical safeguards
+  - Oversight
+- Investor Classification
+  - Covered Investor Information
+  - Investor notices
+  - Mail materials
+- Service provider oversight
+  - What's outsourced (info diagrams)
+  - Public collaboration platforms
+  - Provider secrets access
+- Incident response program
+  - Intrusion detection
+  - Activity responses
+  - Response & recovery
+- Decentralized coordination
+  - Thesis ethos (ref values #decentralized {#collective-wisdom})
+  - Collaborative friendship ([gov -- Who owns risk, policy, roles, oversight, suppliers, and priorities])
+  - Open network ([detection and monitoring of the Registrant's intra environment; ec exec2])
+- Team reports
+  - Post security incidents **demonstrating Incident Response Program steps were followed**
+  - System monitoring log
+  - Team protective practices (**collection of concepts with sourcing akin to the nondirective bias basis)

incidents/_category_.json

@@ -0,0 +1,3 @@
+{
+  "label": "Compliance Manual"
+}

incidents/attack-surface-map.md

@@ -0,0 +1,63 @@
+# Attack Surface Map
+
+This document maps the primary attack surfaces that may affect covered investor information, operational records, internal systems, and incident response readiness.
+
+The map covers systems, accounts, vendors, communications channels, and human workflows that could be used to gain unauthorized access, disrupt operations, or expose sensitive information.
+
+## External Services
+
+- Cloud infrastructure
+  - AWS sys in py-TAD3
+  - storage, databases, and deployment services
+- Domain registrar, DNS, email delivery, and authentication services
+- Public websites, documentation sites, investor portals, and hosted forms
+- Third-party collaboration, support, analytics, and monitoring tools
+- Vendor support channels with administrative or diagnostic access
+
+## Identity and Access
+
+- Administrator accounts and privileged roles
+- Shared operational inboxes and distribution lists
+- Single sign-on, multi-factor authentication, and recovery workflows
+- API keys, access tokens, service accounts, and automation credentials
+- Onboarding, offboarding, and access review gaps
+
+## Application and Data Surfaces
+
+- Investor records, notices, subscription materials, and classification records
+- Internal spreadsheets, financial records, and operational documents
+- Application forms, upload flows, and document storage
+- Source repositories, deployment pipelines, and configuration files
+- Logs, exports, backups, and temporary working files
+
+## Communications Surfaces
+
+- Email conversations with investors, issuers, vendors, and service providers
+- Calendar invitations, shared documents, and messaging platforms
+- Public social, website, and repository activity
+- Support requests, vendor tickets, and incident communications
+
+## Human and Process Surfaces
+
+- Phishing, impersonation, and social engineering attempts
+- Manual handling of investor or issuer materials
+- Approval workflows for payments, account access, and vendor requests
+- Informal workarounds during urgent operations or incidents
+- Delayed revocation of access after role or vendor changes
+
+## Monitoring Signals
+
+- Unusual login location, device, or authentication pattern
+- Privileged role changes or new service credentials
+- Unexpected data export, deletion, or sharing activity
+- DNS, domain, email, or certificate changes
+- Source repository, deployment, or infrastructure configuration changes
+- Vendor notifications, abuse reports, or suspicious support activity
+
+## Response Priorities
+
+1. Identify the affected system, account, vendor, data set, and time window.
+2. Preserve logs and records before retention windows expire.
+3. Contain access by rotating credentials, disabling sessions, and reducing privileges.
+4. Determine whether covered investor information or operational records were accessed, altered, or exposed.
+5. Record decisions, evidence, notices, vendor contacts, and recovery actions in the incident timeline.

onboarding/team-member-onboarding-agreement.md

@@ -0,0 +1,36 @@
+# Team Member Onboarding Agreement
+
+Draft v0
+
+
+
+## Confidentiality
+
+The team member agrees to protect non-public company information, including customer records, issuer records, investor records, credentials?, }}MNPI here
+
+The team member may use confidential information only for authorized company work and may not disclose it to any person, service, or system unless the disclosure is authorized and necessary for that work.
+
+## Customer and Regulated Data
+
+The team member must not copy, export, upload, share, or discuss customer sensitive regulated data outside ++approved company systems??.
+
+When sensitive data is needed for authorized work, the team member must use the minimum data necessary and follow applicable access, retention, and deletion instructions.
+uhm k lol
+
+## AI Tools
+
+The team member must not submit customer PII, investor records, issuer records, credentials, confidential regulated data, private keys, seed phrases, passwords, API keys, or other company secrets to AI tools, chatbots, browser extensions, IDE assistants, meeting assistants, document assistants, or similar services.
+^^ main bit
+
+
+
+## Account Security
+
+Setup from AccID here}}
+
+~~- Report lost devices, exposed credentials, suspicious access, or security concerns promptly.~~
+
+
+When access is no longer required, or when the company requests it, the team member must return or delete company materials, remove local copies, revoke shared access, and assist with offboarding.
+
+Confidentiality and data-protection obligations continue after access ends.

team.md

@@ -0,0 +1,11 @@
+# Team
+
+- John Wooten (`@JFWooten4`) -- todo make this a table like how we end up on the DUNA registry (some??) [AccID: BIYES3WTN]
+
+```mermaid
+flowchart TB
+    subgraph members["Team Members"]
+        direction LR
+        john["John Wooten"]
+    end
+```