Digital Infrastructure and Security
The operating manual for Spiralism’s domains, website, email, accounts, devices, backups, archive storage, access reviews, publishing workflow, and security incidents. The institution’s memory depends on ordinary technical discipline.
Spiralism is text, testimony, media, gatherings, and trust. All of that now passes through digital systems: domain registrars, email accounts, cloud storage, payment processors, recording devices, publishing tools, social accounts, password managers, and archive systems. A small institution can lose years of work through one compromised account, one unbacked-up laptop, one departed founder, or one undocumented service.
The Rule
No single person, account, or device may be the institution.
Every critical digital asset should have:
- an owner;
- a backup owner;
- documented purpose;
- access list;
- recovery method;
- backup method;
- review date;
- offboarding procedure.
If the institution cannot recover a system without the founder’s personal phone, memory, inbox, or laptop, the system is not institutional yet.
Security Frame
Use the NIST Cybersecurity Framework 2.0 functions as the simple operating map:
- Govern — assign ownership, policy, review, and risk decisions.
- Identify — know what assets, data, accounts, and vendors exist.
- Protect — use access controls, MFA, backups, encryption, and training.
-
Detect — notice suspicious logins, missing files, failed backups, and strange account changes.
-
Respond — contain incidents, preserve evidence, notify the right people, and decide next steps.
-
Recover — restore systems, rotate credentials, document lessons, and reduce future risk.
Spiralism does not need enterprise theater. It needs small, repeated controls that match the sensitivity of testimony, donor data, and institutional memory.
Critical Asset Register
Maintain a living register:
Asset:
Type:
Purpose:
Owner:
Backup owner:
Vendor/platform:
URL:
Login method:
MFA method:
Recovery email/phone:
Data sensitivity:
Backup location:
Renewal date:
Payment method:
Access list:
Last reviewed:
Exit procedure:
Track at minimum:
- domain registrar;
- DNS;
- web host;
- static site repository;
- build/deploy process;
- email domain and inboxes;
- newsletter platform;
- archive storage;
- backup storage;
- password manager;
- payment processors;
- donor platform;
- social accounts;
- video channels;
- design assets;
- recording devices;
- laptops or shared devices;
- AI tools approved for public work;
- incident and complaint inboxes.
AI tools require their own register fields: data allowed, data prohibited, default disclosure, review requirement, known risks, and exit plan. The member-facing standard is maintained in AI Literacy and Use Protocol.
Domains and DNS
Domain control is institutional control.
Rules:
-
register domains under the institution or fiscal sponsor as soon as legally practical;
-
use a registrar with MFA;
- document renewal dates;
- turn on auto-renew if payment controls allow it;
- keep DNS records documented;
- avoid founder-only recovery email;
- restrict DNS editing to two or three trained people;
- export DNS records after changes;
- review domain ownership quarterly during the founding period.
A domain lapse is an institutional failure, not a technical inconvenience.
Email is institutional infrastructure, not a convenience.
Minimum standards:
- use institutional addresses for institutional work;
- MFA on all institutional inboxes;
- no shared inbox password;
-
role inboxes where continuity matters, such as
archive@,press@,founders@,corrections@,security@; -
clear forwarding rules;
- quarterly access review;
- documented offboarding;
- export or preserve important correspondence according to record class;
- do not use personal email for restricted testimony or donor records.
The email list is the institution’s most durable public channel. Treat list ownership, export, consent, and unsubscribe integrity as infrastructure. The operating rules for those records are maintained in Contact Records and CRM.
Passwords and MFA
Rules:
- institutional password manager;
- unique password for every service;
- MFA for domain, email, storage, finance, donor, archive, and social accounts;
- hardware security keys for the highest-risk accounts when feasible;
- no MFA tied only to one founder’s personal phone;
- recovery codes stored in the password manager and sealed offline location;
- no shared passwords in chat;
- rotate credentials when a role ends or a device is lost.
FTC small-business cybersecurity guidance emphasizes passwords, MFA, secure storage, and breach response. Spiralism should implement those before adding more tools.
Devices
Devices used for institutional work should meet a basic standard:
- screen lock;
- full-disk encryption where available;
- operating system updates;
- browser updates;
- malware protection where appropriate;
- no shared household profile for restricted work;
- no restricted data stored unencrypted on portable drives;
- lost-device reporting within 24 hours;
- archive media copied off recording devices promptly;
- retired devices wiped before transfer.
Recording devices are archive tools. Treat them like custody devices, not casual accessories.
Website Publishing
The website should remain reproducible.
Rules:
- canonical markdown lives in
docs/; - generated pages live in
site/; - build process documented;
- manual static pages listed separately;
- every new generated page added to the build map;
- internal links checked before publication;
- public pages reviewed for accessibility basics;
- source-linked research pages include sources checked;
- no donation form or intake form added without privacy, finance, and access review.
Publishing authority should be limited. The person who writes a public claim should not be the only person able to deploy it when the claim is high-risk.
Backups
Use a simple rule:
Three copies, two storage types, one geographically separate copy.
Apply it to:
- canonical docs;
- generated website;
- archive packages;
- consent records;
- finance records;
- donor exports;
- role and governance records;
- incident records;
- media masters.
Backups require testing. A backup that has never been restored is a hope, not a control.
Monthly:
- confirm backups ran;
- restore one sample file;
- check archive checksums where applicable;
- confirm offsite copy exists;
- record failures and repairs.
Archive Storage Boundary
The Archive Operations Manual governs preservation packages. This manual governs the systems around them.
Archive storage should:
- separate public, restricted, and highly restricted material;
- use role-based access;
- avoid consumer shared drives for highly restricted material unless reviewed;
- keep consent records linked but access-controlled;
- keep raw testimony out of AI tools unless approved by Privacy and Data;
- log access for restricted material where feasible;
- include succession instructions.
The Archive should never depend on one founder’s cloud subscription.
Digital handoff duties should be reviewed against Succession and Continuity so domains, email, payment processors, archive storage, and public channels remain institutionally recoverable.
Vendor and Tool Review
Before adopting a new tool, ask:
- What data will it hold?
- Who owns the account?
- Can we export our data?
- Does it support MFA?
- Who can access it?
- What happens if the vendor shuts down?
- What are the retention and AI-training terms?
- Can a chapter use it safely?
- What is the cost after the free tier?
- How do we leave?
Free tools are not free if they become custody of the institution’s memory.
Social and Video Accounts
Public accounts should be treated as publishing infrastructure:
- institutional email owner;
- MFA;
- backup owner;
- content archive;
- export where possible;
- no private DMs used for restricted testimony;
- comments and harassment escalation path;
- no account controlled only by a contractor or founder;
- no posting from personal accounts as the institution without review.
If a platform account is lost, the institution should still retain the work.
Access Review
Quarterly review:
- who has domain access;
- who has DNS access;
- who has email admin access;
- who has archive storage access;
- who has donor or finance access;
- who has website deploy access;
- who has social/video access;
- who has AI tool access;
- who has departed and still has access;
- which recovery emails and phones are still valid.
Remove access by role, not by resentment. Access ending is normal.
Incident Response
Digital incidents include:
- lost device;
- compromised account;
- suspicious login;
-
rabbit-hole links, downloads, scripts, QR codes, or credential prompts that may expose members, researchers, or institutional accounts;
-
accidental restricted-data share;
- wrong recipient email;
- public page defacement;
- ransomware or malware;
- payment processor compromise;
- domain or DNS change without approval;
- deleted or corrupted archive data;
- leaked donor, testimony, or complaint record.
First hour:
- Contain the incident.
- Preserve evidence.
- Notify the digital owner and Steward or board contact.
- Rotate credentials if needed.
- Disable exposed access.
- Identify affected data classes.
- Decide whether Privacy and Data, Incident Protocol, Finance, or legal review is triggered.
First week:
- restore from backup if needed;
- notify affected people if required;
- document what happened;
- repair the control that failed;
- update the asset register;
- add the lesson to the quarterly review.
Reddit-style rabbit-hole reports with unsafe links or account-compromise claims are handled first under Forum Rabbit-Hole Response Protocol; do not click, download, paste code, or test suspicious material from an institutional device or logged-in account.
AI agents with tool access should use the prompt, permission, and drift-check standards in Agent Prompt Hardening.
Tool grants and agent accounts should be registered under Agent Tool Permission Protocol.
Agent run records, traces, redaction, and incident review should follow Agent Audit and Incident Review.
Online community spaces should follow Online Community Moderation for unsafe-link handling, moderation logs, AI/bot disclosure, and escalation.
Vendor selection, third-party platform review, supply-chain controls, and exit plans are governed in Vendor and Platform Governance.
Public Security Promise
Use this plain public language:
Digital infrastructure:
Spiralism protects its website, email, archive, donor records, and institutional
accounts with documented ownership, role-based access, MFA, backups, access
reviews, and incident response. The institution does not treat founder memory or
personal devices as infrastructure. Sensitive testimony and donor records are
handled under stricter privacy and archive rules.
Anti-Patterns
Avoid:
- one founder owning the domain personally forever;
- shared passwords in chat;
- MFA tied only to one phone;
- archive data in ordinary email attachments;
- testimony stored only on a recorder or laptop;
- free tools adopted without export review;
- social accounts with no backup owner;
- deleting logs during an incident;
- “we are too small for security”;
- publishing forms that collect sensitive data before storage and access are designed.
First-Year Digital Targets
By the end of Year One:
- asset register exists;
- domain ownership reviewed;
- institutional password manager adopted;
- MFA on all critical accounts;
- backup owners assigned;
- website build process documented;
- monthly backup test performed;
- archive storage boundary reviewed;
- role inboxes established;
- quarterly access review completed;
security@spiralism.orgor equivalent reporting path exists;- digital incident drill completed once.
Sources Checked
- NIST, NIST Cybersecurity Framework 2.0 for Small Business, accessed May 2026.
- NIST, Identify, Protect, Detect, Respond and Recover: The NIST Cybersecurity Framework, accessed May 2026.
- FTC, Cybersecurity Basics, accessed May 2026.
- FTC, Safeguards Rule: What Your Business Needs to Know, accessed May 2026.
- CISA, Recognize and Report Phishing, accessed May 2026.
- CISA, Malware, Phishing, and Ransomware, accessed May 2026.
- Electronic Frontier Foundation, Surveillance Self-Defense, accessed May 2026.
- Electronic Frontier Foundation, Security, accessed May 2026.