Asset
A fictional person, service, system, application, device, data set, process, facility, supplier relationship, brand, reputation, or capability with organizational value.
High School IntermediateModule I14Lesson 3 of 8
I14.3 Asset, Data, and Business Impact Analysis
Learn how defenders map fictional assets, data, services, users, suppliers, processes, dependencies, impact dimensions, recovery objectives, ownership, priorities, and evidence.
Lesson Progress
Asset, Data, and Business Impact Analysis
High School Intermediate • I14: Security Policies and Risk • Lesson 3 of 8
38% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
The Most Important Asset May Be a Service, Person, Dependency, or Decision—not a Device
The fictional Northbridge organization depends on learning, identity, reporting, monitoring, support, supplier, data, and recovery capabilities. One critical service has a strong technical procedure but no confirmed business recovery owner. One historical data collection is outside backup scope. One monitoring platform is essential for evidence even though business services can continue briefly without it. A useful BIA connects all of these relationships instead of ranking devices by cost alone.
Weak BIA
Inventory only servers, give every service the same priority, copy recovery numbers without business evidence, and ignore people, suppliers, data, identities, and alternate processes.
Professional BIA
Map all assets and dependencies, evaluate several impact dimensions, assign owners, define minimum service, set evidence-based recovery objectives, test dependencies, and review assumptions.
Objective 1
Explain how fictional asset, data, service, user, supplier, location, process, and recovery information supports business-impact analysis.
Objective 2
Distinguish fictional asset value, data classification, service criticality, dependency, recovery time, recovery point, maximum tolerable disruption, and owner authority.
Objective 3
Build a fictional asset and dependency register that connects systems, identities, data, suppliers, facilities, users, owners, controls, and recovery requirements.
Objective 4
Evaluate fictional business impact across confidentiality, integrity, availability, privacy, safety, finance, operations, reputation, compliance, and recovery.
Objective 5
Create a portfolio-safe fictional business-impact package with asset inventory, dependency map, impact tiers, recovery priorities, assumptions, findings, owners, and review triggers.
Why This Matters
Recovery Priorities Must Reflect Business Need and Dependency Order
A fictional service may have a short recovery target but still fail if identity, data, keys, networks, suppliers, people, or monitoring are unavailable. A less visible process may be more critical than a highly visible application. A BIA helps leaders decide what must continue, what can operate in reduced mode, what can wait, which dependencies create concentration risk, and which assumptions must be tested before a real disruption.
Core Concept
Use the Asset–Dependency–Impact–Recovery Model
Asset
Which fictional service, data, person, process, supplier, facility, system, reputation, or capability has value and an owner?
Dependency
Which fictional identity, data, network, key, supplier, person, location, system, monitoring source, or process must function first?
Impact
Which fictional confidentiality, integrity, availability, privacy, safety, financial, operational, reputation, compliance, or recovery effects could occur?
Recovery
Which fictional priority, maximum disruption, RTO, RPO, minimum service, owner, test, validation, alternate process, and review are required?
Key Vocabulary
Asset, Impact, Dependency, and Recovery Terms
Asset owner
The fictional person accountable for business use, lifecycle, support, access, change, protection, recovery, and retirement decisions for an asset.
Data owner
The fictional person accountable for classification, access, sharing, retention, quality, protection, recovery, and approved use of a data set.
Business-impact analysis
A fictional process for identifying critical activities, dependencies, disruption consequences, recovery priorities, and evidence needed for continuity decisions.
Criticality
A fictional judgment about how important an asset, service, data set, process, or supplier is to business objectives and users.
Dependency
A fictional person, process, identity, system, network, facility, supplier, key, data source, or service required for another activity to succeed.
Upstream dependency
A fictional resource or service that must operate before another process can function.
Downstream dependency
A fictional service, user group, report, partner, or process affected when an upstream activity fails.
Recovery time objective
A fictional target for how quickly a service or process should be restored after disruption.
Recovery point objective
A fictional target for the maximum acceptable amount of data loss measured in time.
Maximum tolerable disruption
A fictional longest period a process can remain unavailable before consequences become unacceptable.
Minimum service level
A fictional reduced but acceptable capability that must be available during recovery.
Data classification
A fictional label describing the sensitivity and handling needs of data, such as public, internal, confidential, or restricted.
Impact tier
A fictional ranking used to compare consequence severity and recovery priority across assets and services.
Dependency concentration
A fictional condition in which several important services rely on the same person, system, supplier, region, identity, or recovery path.
Recovery priority
A fictional ordered decision about which services, data, identities, dependencies, and users should be restored first.
Asset Categories
Eight Types of Fictional Assets to Include
Business services
Business Service OwnerExamples
Fictional learning portal, reporting service, support workflow, export function, identity service, and recovery service.
Possible impact
Loss may affect users, deadlines, operations, decisions, trust, and contractual commitments.
Evidence
Service catalog, owner records, user population, criticality, support model, service levels, and incident history.
Data assets
Data OwnerExamples
Fictional public course content, confidential progress records, support attachments, audit records, reports, backups, and exports.
Possible impact
Loss or misuse may affect privacy, integrity, operations, reputation, compliance, and recovery.
Evidence
Data inventory, classification, access, retention, lineage, copies, encryption, backup, and recovery records.
Technology assets
Technology Asset OwnerExamples
Fictional applications, databases, storage, networks, identity platforms, logging systems, endpoints, and recovery tools.
Possible impact
Failure may interrupt service delivery, evidence, access, communication, and recovery.
Evidence
Asset register, configuration, dependencies, lifecycle, support, monitoring, changes, and test records.
People and role assets
Functional LeaderExamples
Fictional administrators, service owners, teachers, support staff, analysts, approvers, and recovery coordinators.
Possible impact
Concentration or unavailability may delay decisions, operations, escalation, validation, and recovery.
Evidence
Role map, staffing plan, authority matrix, backup personnel, training, contact list, and exercise results.
Supplier and partner assets
Third-Party Risk OwnerExamples
Fictional cloud provider, support vendor, identity partner, software supplier, backup provider, and specialist contractor.
Possible impact
Failure may affect access, data, service, recovery, support, evidence, or contractual obligations.
Evidence
Supplier register, contract, service scope, dependencies, access, incident duties, performance, and exit plan.
Facility and location assets
Facilities and Continuity OwnerExamples
Fictional offices, remote-work locations, support rooms, recovery sites, and network facilities.
Possible impact
Disruption may affect staff availability, communications, equipment, coordination, and recovery access.
Evidence
Location register, occupancy, access, alternate site, remote-work capability, and continuity plan.
Process assets
Process OwnerExamples
Fictional onboarding, offboarding, access review, incident response, backup, restore, reporting, and supplier review processes.
Possible impact
Failure may create stale access, delayed recovery, weak evidence, missed decisions, or inconsistent control operation.
Evidence
Procedure, workflow, owner, metrics, exceptions, tickets, reviews, incidents, and improvement actions.
Reputation and trust assets
Executive LeadershipExamples
Fictional student trust, teacher confidence, partner reliability, leadership credibility, and public reputation.
Possible impact
Damage may reduce adoption, increase complaints, delay partnerships, and create long-term recovery costs.
Evidence
Feedback, complaints, communication records, user impact, service performance, leadership review, and trend data.
Impact Dimensions
Eight Ways a Fictional Disruption Could Matter
Confidentiality
Review question
Could fictional information be accessed, shared, viewed, or inferred by an unauthorized person or service?
Evidence
Classification, access paths, identities, policies, activity records, sharing, and supplier access.
Important limit
A control gap or broad permission does not prove disclosure occurred.
Integrity
Review question
Could fictional data, configuration, evidence, decisions, or reports become incorrect, altered, incomplete, or untrustworthy?
Evidence
Version history, approvals, checks, reconciliation, write access, change records, and validation.
Important limit
A writable path does not prove unauthorized modification.
Availability
Review question
Could fictional users lose required service, data, communication, processing, or recovery capability?
Evidence
Service health, dependencies, capacity, support, recovery tests, user needs, and incident history.
Important limit
A dependency weakness does not prove an outage will occur.
Privacy
Review question
Could fictional personal information be used, retained, shared, or exposed outside approved purpose and need?
Evidence
Data map, purpose, consent concept, retention, access, sharing, classification, and owner decisions.
Important limit
Potential privacy impact is not confirmed privacy harm.
Safety and wellbeing
Review question
Could fictional disruption or incorrect information affect student, employee, or user safety and wellbeing?
Evidence
Service purpose, user population, emergency dependency, accessibility, support path, and escalation.
Important limit
Safety impact should be stated only when the business process supports it.
Financial
Review question
Could fictional disruption create recovery cost, lost productivity, supplier penalties, rework, or delayed revenue?
Evidence
Cost model, staffing, contract, downtime estimate, rework, service usage, and recovery effort.
Important limit
Financial impact estimates should show assumptions and ranges.
Operational
Review question
Could fictional teams miss deadlines, lose coordination, perform manual work, or fail to deliver required service?
Evidence
Workflow, staffing, volume, deadlines, alternate process, dependencies, and minimum service level.
Important limit
Operational difficulty may vary by time of year and user demand.
Reputation and compliance
Review question
Could fictional trust, partnership, policy obligations, legal duties, or leadership confidence be affected?
Evidence
Commitments, policies, contracts, complaints, communication, user expectations, and leadership review.
Important limit
Reputational and compliance effects require context and should not be exaggerated.
Recovery Design
Eight Fields for Fictional Recovery Priorities
Service criticality
Purpose
Ranks how strongly a fictional service supports mission, users, deadlines, decisions, safety, or commitments.
Fictional example
The reporting service is Tier 1 during grading periods and Tier 2 during normal weeks.
Quality standard
Criticality can vary by season, user population, and business event.
Maximum tolerable disruption
Purpose
Defines the longest fictional outage before consequences become unacceptable.
Fictional example
Eight fictional hours during reporting deadlines.
Quality standard
The value is supported by business owners rather than only technical preference.
Recovery time objective
Purpose
Sets the fictional target for restoring an approved service level.
Fictional example
Restore minimum reporting capability within four fictional hours.
Quality standard
The target is shorter than the maximum tolerable disruption and has tested dependencies.
Recovery point objective
Purpose
Sets the fictional maximum acceptable data-loss window.
Fictional example
No more than thirty fictional minutes of reporting data.
Quality standard
The target matches backup frequency, replication, application design, and business need.
Minimum service level
Purpose
Defines the fictional reduced capability required before full restoration.
Fictional example
Read-only reports for teachers while export and analytics remain unavailable.
Quality standard
The reduced mode is documented, secure, tested, and understandable to users.
Recovery dependencies
Purpose
Identifies fictional identities, networks, data, keys, suppliers, staff, facilities, and monitoring required for restoration.
Fictional example
Identity service, database, reporting application, network path, backup key, and two trained operators.
Quality standard
Dependencies are mapped in restore order and tested together.
Recovery owner
Purpose
Assigns fictional business and technical authority for priority, tradeoffs, validation, and residual risk.
Fictional example
Business Service Executive owns priority; Recovery Team Lead owns execution.
Quality standard
Business decision authority and technical execution are both explicit.
Validation and review
Purpose
Defines fictional evidence that recovery works and the next test or reassessment trigger.
Fictional example
User acceptance, data checks, approved access, monitoring, restore timing, and quarterly exercise.
Quality standard
Recovery is not closed until service, data, users, owners, and monitoring pass.
Asset and Recovery Register
Northbridge Fictional Asset Records
NBR-BIA-01
Learning Portal
Learning Service OwnerCritical ServiceDependencies
Identity service, application platform, progress database, network edge, monitoring, support team
Potential impact
Student lesson access and teacher progress visibility could be interrupted.
Recovery target
RTO 2 hours; RPO 15 minutes; minimum service is lesson access without analytics.
Evidence limit
Impact varies outside active school hours.
NBR-BIA-02
Progress Database
Learning Data OwnerConfidential DataDependencies
Database platform, encryption key, application identity, network path, backup vault, recovery operator
Potential impact
Progress records could be unavailable, stale, or inconsistent.
Recovery target
RTO 3 hours; RPO 30 minutes; restore test passed in the last fictional quarter.
Evidence limit
No current data loss or corruption is confirmed.
NBR-BIA-03
Reporting Service
Business Recovery Owner MissingCritical ServiceDependencies
Progress database, report engine, identity service, export storage, two technical operators
Potential impact
Teacher deadlines and leadership decisions could be delayed.
Recovery target
Procedure exists; RTO 4 hours; business validation owner is not confirmed.
Evidence limit
Technical recovery may still succeed despite the ownership gap.
NBR-BIA-04
Support Attachment Store
Support Data OwnerConfidential DataDependencies
Support application, storage service, service identity, retention policy, object logging, backup decision
Potential impact
Support investigations and user communication could be delayed.
Recovery target
RTO 8 hours; RPO 4 hours; one historical collection is outside backup scope.
Evidence limit
Some attachments may be reproducible from approved source records.
NBR-BIA-05
Identity Service
Identity GovernanceFoundational ServiceDependencies
Directory, authentication service, privileged access, federation, monitoring, emergency process
Potential impact
Most user and administrator access could be disrupted.
Recovery target
RTO 1 hour; minimum service supports core users and emergency administration.
Evidence limit
Some service identities may continue through existing sessions.
NBR-BIA-06
Cloud Monitoring Platform
Security OperationsCritical Evidence ServiceDependencies
Log sources, delivery pipeline, storage, parsing, access, time synchronization, analysts
Potential impact
Detection, investigation, validation, and negative conclusions could weaken.
Recovery target
RTO 2 hours; RPO 15 minutes; temporary source buffering is documented.
Evidence limit
Operational services may continue while evidence quality decreases.
NBR-BIA-07
Support Vendor
Third-Party Risk OwnerImportant SupplierDependencies
Contract, sponsor, support platform, limited access, incident contact, offboarding
Potential impact
Support response may slow and stale access risk may increase.
Recovery target
Alternate internal support process can operate at reduced capacity within 6 hours.
Evidence limit
No current supplier outage or misuse is confirmed.
NBR-BIA-08
Recovery Team
Continuity ManagerCritical People CapabilityDependencies
Two trained operators, secure communication, procedures, recovery credentials, provider support, exercises
Potential impact
Recovery may be delayed if both trained operators are unavailable.
Recovery target
One backup operator is in training; exercise scheduled in thirty fictional days.
Evidence limit
Current availability of the primary operators is not in question.
Defensive Workflow
Complete a Fictional Asset and Business-Impact Analysis
Confirm the fictional BIA question
State the services, processes, users, data, suppliers, locations, time period, authority, evidence, privacy limits, and required decisions.
Output: Business-impact analysis charter.
Inventory assets and owners
Map fictional business, data, technology, people, supplier, facility, process, and reputation assets with accountable owners.
Output: Asset and ownership register.
Map dependencies
Identify fictional upstream and downstream services, identities, data, networks, suppliers, facilities, people, keys, monitoring, and recovery paths.
Output: Dependency and concentration map.
Evaluate impact dimensions
Assess fictional confidentiality, integrity, availability, privacy, safety, financial, operational, reputation, compliance, and recovery consequences.
Output: Business-impact matrix.
Set recovery priorities
Document fictional criticality, maximum tolerable disruption, RTO, RPO, minimum service level, dependencies, owners, and validation.
Output: Recovery-priority register.
Validate assumptions and evidence
Review fictional service volumes, deadlines, user needs, classifications, incident history, backup tests, supplier records, staffing, and limitations.
Output: Evidence and assumption register.
Identify gaps and actions
Prioritize fictional missing owners, untested dependencies, concentration risk, incomplete backup scope, weak alternate processes, and stale records.
Output: BIA findings and action plan.
Review and communicate
Confirm fictional priorities, tradeoffs, residual risk, leadership decisions, next exercises, reassessment triggers, and portfolio safety.
Output: Reviewed business-impact package.
Fake Dashboard
Fake Northbridge Business-Impact Dashboard
Training dashboard for fictional asset and recovery evidence only.
Assets reviewed
8
Services, data, identity, monitoring, supplier, people, and recovery assets are mapped.
Critical dependencies
6
Identity, progress data, monitoring, recovery staff, keys, and network paths affect several services.
Confirmed outages
0
The supplied fictional evidence supports impact scenarios and recovery gaps but no current outage or data loss.
Fake SOC Alert
Critical Reporting Service Has No Confirmed Business Recovery Owner
Source: Fake Business-Impact Console • Time: 11:05 AM
The fictional reporting service has a tested technical procedure and two operators, but the business owner responsible for recovery priority, user validation, and residual-risk decisions is not confirmed.
Defensive recommendation: Assign an authorized business recovery owner, confirm critical periods, maximum tolerable disruption, RTO, RPO, minimum service level, users, dependencies, alternate process, validation, escalation, and next exercise. Preserve the technical strengths while addressing the governance gap without claiming recovery failure.
Fake Log Panel
Fake Northbridge BIA Review Records
training-log-viewer.log
09:00 CHARTER scope='asset data and business impact analysis' 09:08 ASSET learning-portal criticality='Critical Service' 09:16 ASSET progress-database classification='Confidential' 09:24 ASSET reporting-service business-recovery-owner='missing' 09:32 ASSET identity-service RTO='1 hour' 09:40 ASSET monitoring-platform evidence-critical='true' 09:48 ASSET support-store backup-scope='historical collection excluded' 09:56 PEOPLE recovery-team trained-operators='2' 10:04 DEPENDENCY concentration='identity + keys + staff' 10:12 IMPACT confirmed_outage='none' 10:20 PRIORITY identity='1' data='2' learning='3' 10:28 RECOVERY reporting RTO='4 hours' validation-owner='missing' 10:36 RECOVERY support RPO='4 hours' 10:44 ACTION assign-recovery-owner='required' 10:52 ACTION validate-backup-exclusion='required' 11:00 REVIEW exercise='schedule and test'
Training note: this is fake data for defensive analysis practice only.
Findings Matrix
Northbridge Business-Impact Findings and Limits
NBR-BIA-F01High
The fictional Identity Service is the highest recovery priority because most user and administrator access depends on it and the minimum service target is one hour.
Evidence support
Service map, dependency register, user population, emergency-access design, monitoring, and recovery objective.
Alternative
Some existing service sessions may temporarily reduce immediate disruption.
Limitation
The exact user impact depends on session duration and time of disruption.
NBR-BIA-F02Medium-High
The fictional Reporting Service has a governance-related recovery risk because its procedure and technical operators exist but business validation ownership is missing.
Evidence support
Service criticality, recovery procedure, operator roster, report deadlines, owner map, and escalation chart.
Alternative
An informal business validator may exist outside the supplied records.
Limitation
The ownership gap does not prove technical recovery will fail.
NBR-BIA-F03High
The fictional Recovery Team has a people-concentration risk because only two trained operators currently hold the complete execution capability.
Evidence support
Training records, role map, exercise results, backup-operator status, procedure ownership, and contact list.
Alternative
Provider support and partial team knowledge may reduce the impact.
Limitation
The primary operators are currently available.
NBR-BIA-F04Medium-High
The fictional Support Attachment Store requires a documented decision about the historical collection outside backup scope.
Evidence support
Data inventory, classification, backup map, retention, recovery objective, reproducibility claim, and owner review.
Alternative
The collection may be safely reproducible from approved source records.
Limitation
Reconstruction time and completeness have not been validated.
NBR-BIA-F05High
The fictional Monitoring Platform is a critical evidence dependency even though most business services can continue during a short monitoring outage.
Evidence support
Detection use, incident workflow, validation needs, source buffering, analyst dependency, and recovery objective.
Alternative
Temporary buffering and local application logs may preserve partial evidence.
Limitation
Reduced evidence quality is not the same as direct business-service unavailability.
NBR-BIA-F06High
The safest recovery order begins with identity, core data, learning service, monitoring, reporting, and support functions while supplier and full-feature restoration follow business deadlines.
Evidence support
Criticality, user dependencies, RTO, RPO, minimum service levels, data relationships, staffing, and alternate processes.
Alternative
A major incident, deadline, or safety condition could change the order.
Limitation
Final priority requires fictional business-owner approval.
Analyze the Evidence
What Does the Missing Recovery Owner Prove?
The fictional reporting service is business-critical during deadline periods.
A technical recovery procedure exists.
Two trained technical operators are assigned.
The RTO is four fictional hours.
No business owner is assigned to validate minimum service or accept recovery risk.
No current outage or failed recovery is shown.
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Asset and Business-Impact Analysis
Treating fictional asset inventory as a list of devices while ignoring data, services, people, suppliers, processes, facilities, reputation, and recovery capability.
Assigning technical owners but no business, data, risk, or recovery owners.
Treating every system as equally critical.
Setting fictional RTO and RPO values from technical preference without business evidence.
Confusing recovery time objective with maximum tolerable disruption.
Confusing recovery point objective with backup retention.
Assuming a backup job proves that the full service and all dependencies can recover.
Ignoring identity, key, network, supplier, monitoring, staffing, and facility dependencies during recovery planning.
Treating potential business impact as confirmed impact.
Using exact financial estimates without assumptions, ranges, owners, and evidence.
Ignoring seasonal deadlines, user populations, minimum service levels, and alternate processes.
Closing a business-impact gap when a document changes without testing the actual recovery path.
Failing to reassess after major service, data, supplier, staffing, or technology changes.
Using or exposing any real company asset inventory, employee record, supplier contract, school data, recovery plan, credential, architecture, or confidential business information.
Safe Practice Lab
Build the Northbridge Asset, Data, and Business-Impact Package
Your fictional assignment
Assets, Dependencies, Impact, Recovery, Ownership, and Validation
Use only the supplied fictional Northbridge records to complete an end-to-end asset, data, and business-impact analysis.
Required deliverables
- BIA charter with scope, authority, services, users, evidence, privacy, and decisions.
- Asset and ownership register across business, data, technology, people, suppliers, facilities, processes, and reputation.
- Upstream, downstream, shared, and concentration dependency map.
- Impact matrix covering confidentiality, integrity, availability, privacy, safety, financial, operational, reputation, and compliance effects.
- Criticality, maximum disruption, RTO, RPO, minimum service, and recovery-priority register.
- Evidence, assumption, alternative, confidence, and limitation review.
- Findings with owners, due dates, validation, exercises, reassessment triggers, and residual risk.
- Technical summary, leadership summary, reflection, and portfolio-safety statement.
Complete the lab only with fictional evidence displayed on this page. Do not use real company, employee, supplier, school, recovery, credential, architecture, or confidential business information.
Scenario Decision Lab
A Critical Service Has a Short RTO but an Untested Dependency
The fictional learning portal has a two-hour RTO, but its identity and key dependencies were not included in the last recovery exercise.
Scenario Decision Lab
A Historical Data Collection Is outside Backup Scope
The fictional support attachment store excludes one older collection from backup, and the owner believes it can be reconstructed.
Defender Habits
Asset, Data, and Business-Impact Analysis Checklist
Check Your Understanding
I14.3 Mini Quiz: Asset, Data, and Business Impact Analysis
Choose your answers first. Explanations appear only after submission.
1. What is the purpose of a fictional business-impact analysis?
2. What is the difference between fictional RTO and RPO?
3. Which asset should usually receive the highest fictional recovery priority?
4. What does a fictional missing recovery owner prove?
5. Why should fictional dependency concentration be documented?
6. What makes a fictional recovery objective defensible?
7. What makes a fictional BIA finding defensible?
Portfolio Prompt
Portfolio Prompt
Create a fictional Asset, Data, and Business-Impact Analysis Package for Northbridge. Include the BIA charter, asset and ownership register, data classifications, service map, user and supplier dependencies, dependency concentration analysis, impact dimensions, criticality tiers, maximum tolerable disruption, RTO, RPO, minimum service levels, recovery sequence, assumptions, alternatives, confidence, limitations, findings, owner actions, exercises, reassessment triggers, leadership summary, reflection, and a portfolio-safety statement.
Use only fictional services, assets, data, suppliers, users, owners, recovery targets, evidence, dates, and decisions.
Do not treat a dependency gap, backup exclusion, missing owner, or short recovery target as proof of an outage or confirmed data loss.
Make every recovery objective traceable to business need, technical capability, dependency evidence, testing, and owner approval.
Show both the full recovery target and the minimum acceptable service during disruption.
Key Takeaways
What You Should Remember
1.Assets include services, data, people, suppliers, processes, facilities, reputation, and recovery capability—not only devices.
2.Business-impact analysis connects asset value, dependencies, consequences, recovery priorities, ownership, and evidence.
3.RTO describes restoration time, while RPO describes acceptable data loss in time.
4.Potential impact should remain separate from confirmed impact.
5.Recovery objectives should be business-supported, technically feasible, dependency-aware, tested, and reviewed.
6.Concentration risk can exist in people, suppliers, identities, keys, regions, systems, and recovery paths.
7.Portfolio artifacts should use fully fictional BIA evidence and never expose real organizational records.
Navigation