# Architecture & Risk Assessment: Editable template

Behkish Advisory · operated by Kshathra Technologies Inc., Canada

Contact: behkish.nz@outlook.com

**TEMPLATE: replace bracketed fields and remove guidance before issuing.** Do not describe hypothetical scenarios as observed evidence. Do not invent client identities, tests, signatures, credentials, or outcomes.

## Document control

- Client / system: [Name]
- Engagement reference: [Reference]
- Version / date: [Version and date]
- Prepared by: [Name]
- Client reviewer: [Role]
- Information-handling designation: [Agreed designation]
- Review period / evidence cutoff: [Dates]
- Applicable written scope: [Reference]

## 1. Executive decision

**Business objective:** [What decision or outcome does the client need?]

**Recommendation:** [Proceed / proceed with conditions / defer a specific activity / investigate further. Be explicit about what the recommendation covers.]

**Reasons:** [The main tradeoffs and the evidence supporting them.]

**Actions that cannot wait:** [Prioritized list with owners.]

**Decisions the client must make:** [Budget, risk tolerance, requirements, or sequencing.]

**Important limitations:** [Missing evidence, unavailable access, sampling boundaries, and assumptions.]

This is a point-in-time, scoped assessment. It does not establish that a system is secure or compliant, and it does not guarantee production readiness or business results.

## 2. Context and scope

### Business and product context

[Users, product stage, team, operating environment, relevant commitments, and constraints.]

### In scope

- Application / workflow: [Name and boundary]
- Environment: [Named environments agreed for this engagement]
- Repositories / sampled paths: [Named repositories and sampling limits]
- Supplied documents: [Named documents and review limits]
- Stakeholder interviews: [Agreed participants, number, and duration]
- Review activities: [Architecture, trust boundaries, sampled evidence, etc.]

### Out of scope

[Unless separately agreed: penetration testing, exploit attempts, exhaustive source review, formal certification, compliance attestations, legal opinions, benchmark testing, and implementation.]

### Assumptions and dependencies

| Assumption / dependency | Basis | What changes if it is wrong? |
| --- | --- | --- |
| [Assumption] | [Client statement / artifact / inference] | [Impact] |

## 3. Method and evidence register

Explain how evidence was selected and reviewed. Separate supplied documents, statements, observed behavior, executed checks, and inference. Record a check as executed only when it actually occurred.

| Evidence ID | Artifact / statement / check | Source and version / date | Scope examined | Limitations |
| --- | --- | --- | --- | --- |
| E-01 | [Artifact] | [Source] | [Reviewed portion] | [Limit] |

**Unreviewed or unavailable evidence:** [List and implications.]

## 4. Architecture and information flows

Include a diagram or description showing:

- User, identity, and tenant boundaries.
- Applications, databases, storage, queues, and external services.
- Sensitive information, where copies exist, and relevant retention decisions.
- AI retrieval and tool/action permissions where relevant.
- Operational visibility, backup/recovery, and administrative access.

```text
[User] -> [Identity + application API] -> [Authorized data]
                         |
                         v
                 [Background jobs] -> [Approved external service]
                         |
                         v
                    [Draft output] -> [Approval where required]
```

Label proposed changes separately from the current observed architecture.

## 5. Prioritization method

Define the ratings for this engagement and apply them consistently. Explain business impact, plausible exposure, dependencies, and confidence. Do not imply exploitability was verified without evidence.

Suggested starting language:

- **High:** A gap could materially affect confidentiality, authorized actions, sensitive information handling, or a core operating commitment.
- **Medium:** A gap could materially affect reliability, recovery, cost, or the ability to operate and improve the system.
- **Low:** A bounded improvement with limited immediate impact under the stated assumptions.
- **Informational / decision:** A tradeoff or unanswered question that needs an owner rather than a severity assertion.

## 6. Findings summary

| ID | Finding | Priority | Confidence / evidence limits | Owner | Recommended sequence |
| --- | --- | --- | --- | --- | --- |
| F-01 | [Title] | [Rating] | [Confidence] | [Role] | [Timing] |

## 7. Detailed finding: repeat as needed

### F-01: [Specific title]

**Priority:** [Rating]

**Status:** [Observed / inferred / requires confirmation / remediated and checked]

**Evidence:** [Reference exact evidence IDs and explain what was actually examined.]

**Assumptions:** [State any missing context.]

**Why it matters:** [Concrete consequence and affected workflow or information.]

**Recommendation:** [Practical action, sequence, and alternatives if relevant.]

**Acceptance check:** [Observable verification that would demonstrate the intended improvement. State whether proposed or executed.]

**Owner:** [Client role]

**Dependencies:** [Access, product decisions, other changes, or third parties]

**Effort / cost:** [Indicative range with basis, or not estimated; avoid unsupported certainty]

**Residual risk / follow-up:** [What remains and who accepts or investigates it.]

## 8. Roadmap

| Window | Outcome | Actions / finding IDs | Owner | Dependencies | Evidence of completion |
| --- | --- | --- | --- | --- | --- |
| Days 1–7 | [Outcome] | [Actions] | [Role] | [Dependencies] | [Check] |
| Days 8–14 | [Outcome] | [Actions] | [Role] | [Dependencies] | [Check] |
| Days 15–30 | [Outcome] | [Actions] | [Role] | [Dependencies] | [Check] |
| Days 31–90 | [Outcome] | [Actions] | [Role] | [Dependencies] | [Check] |

Windows indicate recommended sequencing unless a separate implementation commitment is agreed. Validate capacity, estimates, and third-party dependencies before scheduling delivery.

## 9. Useful measurements

| Question | Metric / observation | Current evidence | Target / decision owner | How to measure |
| --- | --- | --- | --- | --- |
| [Question] | [Metric] | [Measured value / unknown] | [Agreed target / owner] | [Method] |

Use “unknown” where no baseline exists. Do not imply improvement was measured when it was not.

## 10. Readout and finalization

- Readout date / attendees: [Details]
- Decisions made: [Decision and owner]
- Questions requiring follow-up: [Question, owner, next step]
- Consolidated factual-correction/clarification revision requested: [Date / none]
- Final version issued: [Date and reference]

Assessment scope, delivery dates, readout, review allowance, fee, and payment schedule are agreed in writing for each engagement. Hourly consulting is $200 USD per hour; custom work is quoted separately. Additional investigations, systems, or implementation require written approval before work begins. Applicable taxes and third-party costs are additional unless included. The finalized engagement governs.

## Appendix: limitations and exclusions

[State exactly what was not done; evidence unavailable; restrictions on access; implications for confidence; and any need for specialist follow-up.]

## Appendix: change and decision log

| Date | Change / decision | Reason | Owner / approval | Report version |
| --- | --- | --- | --- | --- |
| [Date] | [Entry] | [Reason] | [Role] | [Version] |