Vendor Security Questionnaire

Vendor Security Questionnaire: Movahedi Solutions and movahedi.ca. This is the filled self-assessment for buyers: 60 questions in 12 categories, dated October 27-29, 2026. It is a self-assessment, not a third-party assessment. It covers the public site movahedi.ca, which stores no client data, and advisory engagement work, where client material is handled only for that engagement. Where a question fits only one of the two, the answer says so. For a tailored response, contact mohammad@movahedi.ca, naming the questionnaire and the deadline.

1. Security baseline

The practiced baseline, stated once:

• Client material: used only for its engagement; never sold; never used to train models; access limited to the people working on that engagement and removed when it ends; returned or deleted at engagement end, on the client's instruction.
• Public site: served over HTTPS through Cloudflare; dated header scan result on Security Practices; SSL Labs grade A; no client data on the site; no visitor or client accounts.
• Incident reporting: report to mohammad@movahedi.ca; the founder triages each report; where client material is affected, the affected client is notified directly. Notification timing for an engagement is agreed in writing for that engagement before material is shared.
• Per-engagement confirmation: storage locations, retention periods, access rules, screening, insurance, and notification timing for an engagement are confirmed in writing for that engagement before material is shared.
• Not held: no SOC 2, ISO 27001, or ISO 42001 certification; no penetration test; no formal published incident response plan; no company insurance policy; no security clearance.

Contents: A Company and services, B Client data handling, C Access control, D Infrastructure and hosting, E Website security, F Vulnerability management, change, and backups, G Incident response, H Compliance, certifications, insurance, and clearance, I Privacy and regulation, J Subprocessors and third parties, K Business continuity and availability, L People, physical security, and contract terms.

Document details

• Vendor: 1000823315 ONTARIO INC., operating as Movahedi Solutions
• Site in scope: movahedi.ca
• Date of this document: Oct 27-29, 2026
• Contact for a tailored response: mohammad@movahedi.ca
• How to use this document: Find the category in the table of contents, read the plain answer first, then read the evidence and detail that follow it. A buyer who stops after the first paragraph of an answer still has the answer. A buyer who keeps reading has the proof, the limits, and the related sections to check next.
• Scope note: This questionnaire covers two things and keeps them separate: the public site movahedi.ca, which stores no client data, and advisory engagement work, where client material is handled only for that engagement under the rules in Category B and Category L. Where a question fits only one of the two, the answer says so.

Change record

• October 29, 2026: security baseline added for multi-factor authentication (founder self-attestation for email, GitHub, and Cloudflare accounts); internal drafting notes removed; document dates standardized to October 27-29, 2026; section numbering corrected.
• October 27-28, 2026: initial publication: 60 questions in 12 categories, with dated evidence entries.

Summary counts

Total questions: 60

• Answered with evidence: 24
• Answered not held: 18
• Answered not applicable: 4
• Answered to be confirmed in writing per engagement: 14

Total: 24 + 18 + 4 + 14 = 60

Status meanings used in every answer:

• Answered with evidence: the answer is supported by a dated source named in that answer.
• Answered not held: the vendor does not hold the item asked about, and the answer says so plainly.
• Answered not applicable: the question does not fit this service model, and the answer gives the reason.
• Answered to be confirmed in writing per engagement: the answer depends on the terms of a specific engagement, and it must be confirmed in writing for that engagement. It is not stated here as a general claim.

Table of contents

1. Security baseline
2. Evidence index: dated entries
3. Category A: Company and services (A1 to A5)
4. Category B: Client data handling (B1 to B5)
5. Category C: Access control (C1 to C5)
6. Category D: Infrastructure and hosting (D1 to D5)
7. Category E: Website security (E1 to E5)
8. Category F: Vulnerability management, change, and backups (F1 to F5)
9. Category G: Incident response (G1 to G5)
10. Category H: Compliance, certifications, insurance, and clearance (H1 to H5)
11. Category I: Privacy and regulation (I1 to I5)
12. Category J: Subprocessors and third parties (J1 to J5)
13. Category K: Business continuity and availability (K1 to K5)
14. Category L: People, physical security, and contract terms (L1 to L5)
15. Request route for a tailored response

2. Evidence index: dated entries

Each entry below is a separate dated record. A question that relies on an entry names that entry again in its evidence paragraph.

2.1 Public site

• Entry: movahedi.ca, live public site.
• Date in this document: Oct 27-29, 2026.
• Source: live public site at https://movahedi.ca
• Detail: The site is built and deployed from GitHub and delivered through Cloudflare over HTTPS. No specific GitHub plan and no specific Cloudflare plan is claimed in this document.

2.2 Third-party header scan

• Entry: Security Headers scan of movahedi.ca.
• Date: Oct 28, 2026, 00:59 UTC.
• Source: third-party scan at https://securityheaders.com/?q=https://movahedi.ca&followRedirects=on
• Result: see Security Practices.
• Headers passed: Strict-Transport-Security with preload, Content-Security-Policy, Permissions-Policy, Referrer-Policy, X-Content-Type-Options, X-Frame-Options.
• Limit: header scan only, not a penetration test.

2.3 Privacy Policy

• Entry: Privacy Policy for movahedi.ca.
• Date: last updated October 29, 2026.
• Source: Privacy Policy for the public site, as published on movahedi.ca.
• Detail: The policy date is stated here as October 29, 2026. No later policy date is claimed.

2.4 Registration: UNGM

• Entry: UNGM Basic registration.
• Identifier: 1295964.
• Date in this document: Oct 27, 2026.
• Detail: Listed as a registration only. It is not a certification, and it is not presented as one.

2.5 Registration: MERX

• Entry: MERX Basic Free registration.
• Date in this document: Oct 27, 2026.
• Detail: Listed as Basic Free, with no paid subscription claim and no payment method claim.

2.6 Registration: CanadaBuys and SAP Ariba

• Entry: CanadaBuys supplier profile route through SAP Ariba.
• Identifier: AN11542201146.
• Date in this document: Oct 27, 2026.
• Detail: Listed as a registration identifier only. It is not a certification, and no clearance claim follows from it.

2.7 Registration: CPSS ePortal

• Entry: CPSS ePortal registration.
• Date in this document: Oct 27, 2026.
• Detail: Listed as a registration only. No outcome beyond registration is claimed from this entry alone.

2.8 Registration: Ontario Tenders Portal

• Entry: Ontario Tenders Portal registration.
• Date in this document: Oct 27, 2026.
• Detail: Listed as a registration only. No contract, award, or outcome is claimed from this entry.

2.9 Third-party profile: LinkedIn Services

• Entry: LinkedIn Services profile for Movahedi Solutions.
• Date in this document: Oct 27, 2026.
• Detail: Listed as a third-party profile only. No client, testimonial, or outcome is claimed from this entry.

2.10 Third-party profile: Catalant

• Entry: Catalant profile for Movahedi Solutions.
• Date in this document: Oct 27, 2026.
• Detail: Listed as a third-party profile only. No client, testimonial, or outcome is claimed from this entry.

2.11 Third-party profile: Clutch

• Entry: Clutch profile for Movahedi Solutions.
• Date in this document: Oct 27, 2026.
• Review count: 0 reviews.
• Detail: The count is stated as 0. No review, rating claim beyond the count, testimonial, or client name is added to it.

2.12 Third-party profile: Trustpilot

• Entry: Trustpilot profile for Movahedi Solutions.
• Date in this document: Oct 27, 2026.
• Review count: 0 reviews.
• Rating: no rating displayed (0 reviews); 0.0 is the absence of a score, not a score.
• Detail: The count and the rating are stated as they stand. No review text, testimonial, or client name is added to them.

2.13 Founder credentials, personal only

• Entry: Founder credentials.
• Credentials: ISC2 CC, CIPP/C, Lean Six Sigma coursework (LinkedIn Learning, 2022).
• Date in this document: date of each credential is not stated in this document.
• Detail: These are personal credentials of the founder. They are not company certifications, and no company certification is claimed from them.

2.14 Trust Center versions

• Entry: this questionnaire.
• Date: Oct 27-29, 2026.
• Detail: linked from the Trust Center Documents section and the Security Questionnaire Answers section.

Category A: Company and services

A1. What is the legal name, trade name, location, and business type of the vendor?

Answer: The vendor is 1000823315 ONTARIO INC., operating as Movahedi Solutions, an independent privacy and AI governance consultancy based in Mississauga, Ontario, Canada.

Evidence: Company record in this document, dated Oct 27, 2026. Site in scope: https://movahedi.ca

Detail: The legal name and the trade name are both given, so a buyer can match procurement records to the correct entity. The business type is stated as an independent consultancy, which sets the scope for the rest of this questionnaire: this is an advisory firm, not a hosted software provider, not a data centre operator, and not a reseller. No parent company, subsidiary, or group structure is claimed in this document. Staffing for a specific engagement is covered separately in A4, where it is answered directly.

Related: Trust Center Documents section; Trust Center Security Questionnaire Answers section; A4; A5; L5.

Status: Answered with evidence

A2. What services does the vendor provide?

Answer: AI Governance; Privacy and Data Governance; Cookie and Script Governance; Process Excellence; Custom AI and Data Solutions; Fractional Advisory. Detail: Services.

Evidence: Service record in this document, dated Oct 27, 2026. Site in scope: https://movahedi.ca

Detail: Each service is an advisory service, delivered as analysis, frameworks, inventories, and assessments. These are services, not certifications and not client outcomes. No result for a specific client is claimed from listing a service, and no client name is attached to any service in this document. The work pattern behind these services is legal research and governance analysis: reading the relevant law and guidance, mapping it to a client's activities and data, and producing a framework, inventory, or assessment the client can act on.

Related: Trust Center Documents section; I1; I2; I3; J2; L5.

Status: Answered with evidence

A3. What is the contact route for security, privacy, and procurement questions?

Answer: mohammad@movahedi.ca.

Evidence: Contact record in this document, dated Oct 27, 2026. Site in scope: https://movahedi.ca

Detail: One contact route is given for all three kinds of question, so a buyer does not need to guess which address fits a security question versus a procurement question. This route is also the route for a tailored response, for incident notice under G2, and for the per-engagement confirmations described in this document. No phone number, portal, or ticket system is claimed as a security contact route in this document, because none is stated in the evidence stated in this document.

Related: Trust Center Documents section; G2; L5; Section 15, Request route for a tailored response.

Status: Answered with evidence

A4. How large is the vendor, and how is it staffed?

Answer: Movahedi Solutions is an independent consultancy. Staffing for a specific engagement, including who will work on it and what they will cover, is agreed in writing for that engagement.

Evidence: Business type record in this document, dated Oct 27, 2026.

Detail: Evidence for this answer is limited to the items stated below. The independent consultancy shape is stated, and the rest is left for per-engagement confirmation. For a buyer, the practical effect is clear: staffing for an engagement, including who will work on it and what screening or security steps apply to those people, must be confirmed in writing before work starts. That confirmation is where L1 and L2 connect to this answer.

Related: Trust Center Documents section; H4; L1; L2.

Status: Answered to be confirmed in writing per engagement

A5. What registrations and third-party profiles does the vendor hold?

Answer: The vendor holds the registrations and third-party profiles listed as separate dated entries below. Each entry is a registration or a profile only, not a certification and not a contract award.

Evidence: Dated entries in Section 2.4 to Section 2.12, all dated Oct 27, 2026, plus the site at https://movahedi.ca

Detail: The entries are given one by one, so each can be checked on its own:

• UNGM Basic, identifier 1295964, dated Oct 27, 2026. Registration only.
• MERX Basic Free, dated Oct 27, 2026. Basic Free only, with no paid subscription claim and no payment method claim.
• CanadaBuys route through SAP Ariba, identifier AN11542201146, dated Oct 27, 2026. Registration identifier only.
• CPSS ePortal registration, dated Oct 27, 2026. Registration only.
• Ontario Tenders Portal registration, dated Oct 27, 2026. Registration only.
• LinkedIn Services profile, dated Oct 27, 2026. Profile only.
• Catalant profile, dated Oct 27, 2026. Profile only.
• Clutch profile, dated Oct 27, 2026, with 0 reviews. Count stated as 0, with no review text added.
• Trustpilot profile, dated Oct 27, 2026, with 0 reviews and no displayed rating (0.0 reflects no reviews, not a score). Count stated as it stands, with no review text added.

No entry in this list is used to imply a client relationship, an award, a testimonial, or a clearance. A buyer who needs the current status of any single entry should ask for a fresh confirmation for that entry, using the route in Section 15.

Related: Trust Center Documents section; Trust Center; H1; H2; H3; J1.

Category B: Client data handling

Legal scope note for this category: The rules below are company rules for handling client material. They set the default position for an engagement. Where a client needs a different rule, a stricter rule, or a specific security, screening, or insurance requirement, that rule must be confirmed in writing per engagement, before work starts. This category does not give legal advice for a specific client matter.

Status: Answered with evidence

B1. What client data does the public site movahedi.ca store?

Answer: None. The public site stores no client data on it.

Evidence: Site scope record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: This answer covers the public site only, and it is the reason several later answers are marked not applicable. A public advisory site is not a client data store, not a client portal, and not a hosted application holding client records. Engagement material is handled separately from the public site, under B2 and B5. A buyer assessing the public site therefore assesses a site with no client data on it, while a buyer assessing an engagement assesses the engagement rules in this category.

Related: Trust Center Security Practices section; Privacy Policy; C5; D5; F3.

Status: Answered with evidence

B2. How may client engagement material be used?

Answer: Client material is used only for its own engagement. It is not sold, it is not used for model training, and it is not used for any unrelated purpose.

Evidence: Client data rules record in this document, dated Oct 27, 2026.

Detail: The limit is stated as a use limit, not only as a storage limit. Use only for its engagement means the material does not move to another engagement, to marketing, to a public example, or to training data. No sale means no transfer of client material for payment or other value to an unrelated party. No model training use means client material is not fed into model training, whether for the vendor's own models or for a third party's models. If an engagement needs a use beyond this default, that use must be confirmed in writing per engagement, before the material is used that way. Silence is not consent to a wider use.

Related: Trust Center Documents section; Privacy Policy; B5; I5; J5.

Status: Answered with evidence

B3. What retention period applies to client engagement material?

Answer: The policy is return or deletion at engagement end, on the client's instruction. A client that needs a specific retention period sets it in writing for that engagement before work starts, and that written period then governs.

Evidence: Client data rules record in this document, dated Oct 27, 2026. End-of-engagement rule in B5.

Detail: End of engagement triggers removal as the default; client instruction triggers return or deletion, as the client directs. The timing and the proof of return or deletion for a specific engagement, for example a confirmation note or a deletion record, are confirmed in writing per engagement. No copy is retained for an unrelated purpose after removal under B2.

Related: Trust Center Documents section; B5; F5; L5.

Status: Answered to be confirmed in writing per engagement

B4. Where is client engagement material stored, and what residency applies?

Answer: No standing residency commitment is made. Storage location and residency for an engagement are confirmed in writing for that engagement before material is shared.

Evidence: Client data rules record in this document, dated Oct 27, 2026.

Detail: Residency can affect which privacy law applies and which transfer rules apply, so a location commitment belongs in the written terms for that engagement, before material is shared. The public site position is separate: the public site is delivered through Cloudflare over HTTPS, and stores no client data under B1.

Related: Trust Center Documents section; D1; D4; J2; L5.

Status: Answered to be confirmed in writing per engagement

B5. What happens to client material at the end of an engagement, or on client instruction?

Answer: Client material is removed at the end of the engagement, and it is returned or deleted on client instruction.

Evidence: Client data rules record in this document, dated Oct 27, 2026.

Detail: Two triggers are given, and both are client-controlled in effect. End of engagement triggers removal as the default. Client instruction triggers return or deletion, as the client directs. Return and deletion are stated as alternatives chosen by the client, not as a vendor choice made for the client. The timing and the proof of return or deletion for a specific engagement, for example a confirmation note or a deletion record, must be confirmed in writing per engagement, because this general rule does not by itself state a deadline or a proof format. No copy is retained for an unrelated purpose after removal under B2.

Related: Trust Center Documents section; B2; B3; J5; L5.

Category C: Access control

Status: Answered with evidence

C1. Who can access client engagement material?

Answer: Access is limited to the people working on that engagement.

Evidence: Client data rules record in this document, dated Oct 27, 2026.

Detail: Limited access is the general rule, and it is tied to the engagement, not to the firm as a whole. Material for one engagement is not open to people working only on another engagement, and it is not open for general browsing. The named people, their roles, and any client approval step for adding a person must be confirmed in writing per engagement, because this general rule does not name individuals. That per-engagement confirmation is also where screening requirements under L1 connect to access: a client who needs a screening step should set it before access is granted, not after.

Related: Trust Center Security Practices section; A4; L1; J2.

Status: Answered with evidence

C2. Is multi-factor authentication used for accounts that can reach engagement material or site accounts?

Answer: Yes. Multi-factor authentication is enabled on the founder's email (Google Workspace), GitHub (site source), and Cloudflare (site hosting and DNS) accounts. The public site has no visitor login, so no visitor account needs it.

Evidence: Founder confirmation, October 29, 2026. This is self-attested by the founder, not third-party verified.

Detail: This covers the firm's own accounts. Engagement-specific tools, such as shared folders or a client's systems, are a separate matter: whether multi-factor authentication applies to those accounts must be confirmed in writing per engagement, naming the accounts and the method, before material is shared. No password length, rotation, or single sign-on provider is stated here, because none was checked.

Related: Trust Center Security Practices section; C3; C4; D1.

Status: Answered to be confirmed in writing per engagement

C3. What password and single sign-on rules apply?

Answer: No password rule and no single sign-on rule is stated in this document. Both must be confirmed in writing per engagement where they apply to that engagement.

Evidence: No password or single sign-on record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: The public site has no visitor login, so no visitor password rule arises from the public site itself, as stated in C5. Engagement accounts, shared folders, and tools used for a specific engagement are a separate matter, and their password and sign-on rules depend on the tools agreed for that engagement. Those rules must be set in writing for that engagement, before access is granted. No password length, rotation, or sign-on provider is named here, because none is verified in the evidence stated in this document.

Related: Trust Center Security Practices section; C2; C5; J2.

Status: Answered to be confirmed in writing per engagement

C4. How often is access reviewed, and how is access removed when a person leaves an engagement?

Answer: No review frequency and no removal timetable is stated in this document. Both must be confirmed in writing per engagement.

Evidence: No access review record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Access review and removal matter most at the points where risk changes: a person joins, moves, or leaves an engagement, and an engagement ends. The general rule in C1 limits access to people working on the engagement, and B5 removes material at engagement end, but neither states a review date or a removal deadline. A buyer who needs a review cadence, a removal deadline, or a confirmation of removal should set it in writing for that engagement, before work starts. This keeps the commitment tied to the engagement where it can be checked, rather than stated as a general figure with no source.

Related: Trust Center Security Practices section; B5; C1; L1.

Status: Answered to be confirmed in writing per engagement

C5. How are visitor or client accounts provisioned on movahedi.ca?

Answer: They are not provisioned, because the public site has no visitor or client accounts.

Evidence: Site scope record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: A question about account provisioning assumes accounts exist. On a public site with no login for visitors and no client portal, that assumption does not hold. There is no joiner, mover, or leaver process for public site visitors, because there is no visitor account to join, move, or leave. Engagement access is a separate matter and is covered in C1 to C4, where per-engagement confirmation applies. Marking this answer not applicable is more accurate than inventing an account process for a site that has no accounts.

Related: Trust Center Security Practices section; B1; C1; C3.

Category D: Infrastructure and hosting

Status: Answered not applicable

D1. How is movahedi.ca built, deployed, and delivered?

Answer: The site is built and deployed from GitHub, and it is delivered through Cloudflare over HTTPS.

Evidence: Technology record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: The pattern is source control plus managed delivery. Source and deployment sit with GitHub, so the site can be rebuilt from source. Delivery sits with Cloudflare, over HTTPS, so visitors reach the site over an encrypted transport. The site was built and improved over many sessions before Oct 27-29, 2026, with the exact date of each earlier session not stated in this document. No self-managed server is claimed in this model, which is why F3 is marked not applicable. No specific GitHub plan and no specific Cloudflare plan is claimed, as stated in D2.

Related: Trust Center Security Practices section; D2; E1; F1; K5.

Status: Answered with evidence

D2. What GitHub and Cloudflare plans are used?

Answer: No specific plan is claimed in this document for GitHub or for Cloudflare.

Evidence: No plan record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Evidence for this answer is limited to the items stated below. The providers are named in D1, because the delivery model depends on them, but the commercial plan tier for each provider is not stated in the evidence stated in this document, so it is not stated here. A buyer who needs a plan tier, a feature tied to a tier, or a provider term should ask for a fresh confirmation for that provider, using the route in Section 15. A plan tier stated without a source would not help a buyer check it, so none is given.

Related: Trust Center Security Practices section; D1; J1.

Status: Answered not held

D3. What encryption standard applies to client engagement material?

Answer: No encryption standard for client engagement material is claimed in this document. The encryption and transfer method for an engagement must be confirmed in writing per engagement.

Evidence: No encryption standard record for client material is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: This answer must be kept separate from the public site position. For the public site, delivery over HTTPS is stated in D1 and E1, and the header scan in E2 confirms Strict-Transport-Security with preload. That site transport position does not by itself state an encryption standard for client engagement material sent or stored during an engagement. The engagement method, including how files are transferred and how stored material is protected, must be agreed in writing for that engagement, before material is shared. No standard name, key length, or algorithm is given here, because none is verified for client material in this document.

Related: Trust Center Security Practices section; D1; E1; E2; J2.

Status: Answered to be confirmed in writing per engagement

D4. Where is the site hosted, and where is client material held?

Answer: No hosting location and no client material location is stated in this document. Both must be confirmed in writing per engagement where a location commitment is needed.

Evidence: No location record is stated in the evidence stated in this document, dated Oct 27, 2026. Site: https://movahedi.ca

Detail: The delivery providers are named in D1, but a provider name is not a location. Cloudflare delivery and GitHub source control do not by themselves state a single hosting location for the public site, and they do not state a location for engagement material. For the same legal reason given in B4, a location commitment for engagement material belongs in the written terms for that engagement, before material is shared. No data centre name, city, or country is added here for either the site or engagement material.

Related: Trust Center Security Practices section; B4; D1; J1.

Status: Answered to be confirmed in writing per engagement

D5. How is client data separated from other clients in a shared system?

Answer: There is no shared client system to separate, because the public site stores no client data and no multi-tenant hosted application is claimed.

Evidence: Site scope record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: Separation controls assume a shared store where one client's data sits beside another client's data. That model does not fit an advisory firm whose public site holds no client data under B1, and whose engagement material is limited to its own engagement under B2. Separation in this model is engagement separation: material is used only for its engagement, access is limited to people working on that engagement under C1, and material is removed at engagement end under B5. A buyer who needs a technical separation statement for a hosted system should not rely on this answer, because no such hosted system is claimed.

Related: Trust Center Security Practices section; B1; B2; C1.

Category E: Website security

Status: Answered not applicable

E1. Is movahedi.ca served over HTTPS?

Answer: Yes. The site is served over HTTPS.

Evidence: Technology record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: HTTPS delivery is the transport position for the public site, and it is consistent with the header scan result in E2, which passed Strict-Transport-Security with preload. HTTPS for the public site does not by itself answer the engagement encryption question in D3, and it is not used here as if it did. The two questions are kept separate: site transport is evidenced here, engagement material protection is confirmed per engagement under D3.

Related: Trust Center Security Practices section; D1; E2; D3.

Status: Answered with evidence

E2. What independent check supports the site security header position?

Answer: A third-party header scan by Security Headers, dated Oct 28, 2026, 00:59 UTC. The result is recorded on Security Practices.

Evidence: Third-party header scan, dated Oct 28, 2026, 00:59 UTC, at https://securityheaders.com/?q=https://movahedi.ca&followRedirects=on

Detail: This is a header scan only. The grade and the date are stated, and the scan link is given so a buyer can re-run or re-check the same scan. The scan is the most recent dated technical evidence in this document. No wider security claim is drawn from this scan than the headers it checked, and the header list is given in full in E3.

Related: Trust Center Security Practices section; Trust Center Documents section; E1; E3; E4.

Status: Answered with evidence

E3. Which security headers passed in that scan?

Answer: Strict-Transport-Security with preload, Content-Security-Policy, Permissions-Policy, Referrer-Policy, X-Content-Type-Options, and X-Frame-Options all passed.

Evidence: Third-party header scan, dated Oct 28, 2026, 00:59 UTC, at https://securityheaders.com/?q=https://movahedi.ca&followRedirects=on

Detail: Each header is named, rather than summarised as headers in general, so a buyer can match the list to the scan result. Strict-Transport-Security with preload means the site asks browsers to use HTTPS, including on first visit where preload applies. Content-Security-Policy, Permissions-Policy, Referrer-Policy, X-Content-Type-Options, and X-Frame-Options each constrain a different browser behaviour, and all six are recorded as passed in the same scan. No header value, policy text, or configuration detail beyond the passed list is stated here, because no such detail is given in the scan summary record in this document. A buyer who needs the full header values should re-run the scan at the link above and compare the live result to this dated result.

Related: Trust Center Security Practices section; E1; E2; E4.

Status: Answered with evidence

E4. Has movahedi.ca had a penetration test?

Answer: No penetration test is claimed in this document.

Evidence: No penetration test record is stated in the evidence stated in this document, dated Oct 27-29, 2026. The only dated technical check in this document is the header scan in E2.

Detail: The distinction matters, and it is kept explicit in every place the scan appears. A header scan checks response headers. A penetration test probes for exploitable weaknesses. One is not the other, and a header scan result does not become a penetration test result by being repeated. A buyer who needs a penetration test should require it as a separate, written commitment, with scope, tester, date, and findings handling agreed before work starts. Until such a test exists and is recorded, this answer stays not held.

Related: Trust Center Security Practices section; E2; E3; F4.

Status: Answered not held

E5. What monitoring tool watches the public site?

Answer: No monitoring tool is named in this document.

Evidence: No monitoring tool record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Evidence for this answer is limited to the items stated below. Naming a tool without a verified configuration record would give a buyer a name to trust with no way to check it. The dated evidence that does exist for the public site is the live site itself and the Oct 28, 2026 header scan in E2. Monitoring, alerting, and log review for a specific engagement, where they apply, must be confirmed in writing per engagement, as covered in F4 and F5. No uptime figure follows from this answer, and none is claimed in K1 either.

Related: Trust Center Security Practices section; E2; F4; K1.

Category F: Vulnerability management, change, and backups

Status: Answered not held

F1. How is site source controlled and deployed?

Answer: Site source and deployment sit with GitHub, and delivery sits with Cloudflare over HTTPS.

Evidence: Technology record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: The pattern is a managed source and delivery chain, not a hand-edited live server. Changes go through source control, deployment comes from that source, and delivery comes through Cloudflare. That pattern also supports recovery of the public site: the site can be rebuilt from source, rather than depending on a single live copy. The exact review step for each change is covered separately in F2, where the exact step is described, so this answer does not overstate F1 into a full change approval claim.

Related: Trust Center Security Practices section; D1; F2; K2.

Status: Answered with evidence

F2. What change approval process applies to site and engagement changes?

Answer: Site changes go through source control and an automated release pipeline; a failed check means no deploy. The change process for a specific engagement is confirmed in writing per engagement.

Evidence: Release process record in this document, dated Oct 29, 2026.

Detail: For the public site, changes are committed to source control, and an automated pipeline runs the build, a style check, and an internal link integrity check before any deploy. A change that fails the build, the style check, or the link check does not go live; the previous version keeps serving. Copy and link checks also run before publish, and a publish with a broken internal link does not go forward. For an engagement, the change process, including who approves a framework change, an inventory change, or a scope change, depends on the engagement and is agreed in writing before work starts. A buyer who needs a change log or an approval record for an engagement should require that record format in the written terms.

Related: Trust Center Documents section; F1; A2; L5.

Status: Answered with evidence

F3. What patching schedule applies to vendor-managed servers?

Answer: No patching schedule applies, because no self-managed server is claimed in this model.

Evidence: Technology record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: Patching assumes a server the vendor manages and patches. The model in D1 uses GitHub for source and deployment and Cloudflare for delivery, with no self-managed server in scope. Platform patching for those providers sits with those providers, and no provider patching schedule is claimed here. Engagement work does not add a vendor-managed server either, since no hosted application is claimed in D5. A buyer assessing patching should therefore assess the provider model in D1, not a vendor server schedule that does not exist in this model.

Related: Trust Center Security Practices section; D1; D5; J1.

Status: Answered not applicable

F4. What vulnerability scanning schedule and tool are used?

Answer: No vulnerability scanning schedule and no scanning tool are claimed in this document.

Evidence: No scanning schedule or tool record is stated in the evidence stated in this document, dated Oct 27, 2026. The dated technical check that does exist is the header scan in E2.

Detail: The header scan in E2 is not a vulnerability scan, and it is not counted here as one. A vulnerability scan would check for known weaknesses on a schedule, with findings handling and retesting. No such schedule, tool, or findings record is stated in this document. A buyer who needs vulnerability scanning should require it in writing for the relevant scope, with schedule, scope, and findings handling agreed before work starts. Until that commitment exists and is recorded, this answer stays not held, rather than borrowing the header scan grade to imply a wider testing position.

Related: Trust Center Security Practices section; E2; E4; E5.

Status: Answered not held

F5. What backup schedule applies?

Answer: No backup schedule is stated in this document. The backup and recovery position for an engagement must be confirmed in writing per engagement.

Evidence: No backup schedule record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Two scopes must be kept apart. For the public site, source in GitHub supports a rebuild from source under F1, but no backup schedule, backup location, or restore timetable is claimed from that pattern alone. For engagement material, backup depends on the tools and the written terms for that engagement, including how long a working copy is kept and how it is removed at engagement end under B5. No schedule in days, no retention figure for backups, and no restore time is given here, because none is verified in the evidence stated in this document. A buyer who needs a backup commitment should set it in writing for that engagement, before material is shared.

Related: Trust Center Documents section; B5; F1; K2; K3.

Category G: Incident response

Status: Answered to be confirmed in writing per engagement

G1. Is there a formal, published incident response plan?

Answer: No formal, published incident response plan is claimed. The practiced baseline is stated in the Security baseline above: report to mohammad@movahedi.ca, the founder triages each report, and where client material is affected the affected client is notified directly.

Evidence: Contact route in G2, dated Oct 27, 2026.

Detail: A full plan would name roles, escalation steps, containment steps, communication steps, and post-incident review. Those plan elements are not stated generally here. A buyer who needs a plan should require it in writing for the relevant engagement, with roles and steps agreed before work starts.

Related: Trust Center Security Practices section; G2; G3; G5.

Status: Answered not held

G2. What is the incident contact route?

Answer: mohammad@movahedi.ca.

Evidence: Contact record in this document, dated Oct 27, 2026.

Detail: The same route given in A3 is the incident route, so a buyer does not need a second address for incidents. The route is stated, but the notification timing is not stated generally, and it is covered separately in G3 as a per-engagement confirmation. Keeping route and timing separate matters: a route that exists is evidenced, while a timing commitment that depends on the engagement is not overstated as a general service level figure.

Related: Trust Center Security Practices section; A3; G1; G3.

Status: Answered with evidence

G3. How quickly will a client be notified of an incident affecting its material?

Answer: Where client material is affected, the affected client is notified directly by the founder. The notification timetable for an engagement is agreed in writing for that engagement before material is shared.

Evidence: Contact route in G2, dated Oct 27, 2026.

Detail: Notification timing is a contractual commitment and can carry regulatory consequences depending on the data and the jurisdiction. A buyer should set the timetable in writing for that engagement, before material is shared, including what counts as a notifiable incident, who is notified, and by which route.

Related: Trust Center Security Practices section; G2; B4; I4; L5.

Status: Answered to be confirmed in writing per engagement

G4. Has the vendor had a security incident affecting client material in the past 12 months?

Answer: No incident history claim is made in this document.

Evidence: No incident history record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: This answer does not state that no incident ever occurred, and it does not state that an incident did occur. It states that no history claim is made here, so a buyer does not rely on a history statement with no source. A buyer who needs a history statement for a specific period should ask for it as a tailored response, using the route in Section 15, with the period and the scope stated in the request. That tailored answer can then be checked against its own date and scope, rather than read as a general claim in this questionnaire.

Related: Trust Center Documents section; G1; G2; Section 15.

Status: Answered not held

G5. Has incident response been tested through a simulation or tabletop exercise?

Answer: No simulation or exercise claim is made in this document.

Evidence: No testing record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Testing a plan and having a contact route are different things. G2 gives a route, G1 states that no formal published plan is claimed, and this answer adds that no test of such a plan is claimed either. A buyer who needs a tested plan should require the test, with date, scope, and lessons, in writing for the relevant engagement. Until that record exists, this answer stays not held, and no exercise date is invented to fill it.

Related: Trust Center Security Practices section; G1; G2; K4.

Category H: Compliance, certifications, insurance, and clearance

Status: Answered not held

H1. Does the company hold SOC 2?

Answer: No. The company holds no SOC 2 certification.

Evidence: Company certification record in this document, dated Oct 27, 2026.

Detail: The answer is a plain no, with no qualifier and no implied equivalent. No SOC 2 report, report period, auditor name, or scope is claimed, because none exists in the record in this document. A buyer who needs SOC 2 assurance should not treat any other item in this document, including the header scan in E2 or the founder credentials in H4, as a substitute for SOC 2. Those items are different, and they are labelled as different.

Related: Trust Center Documents section; H2; H3; H4; H5.

Status: Answered not held

H2. Does the company hold ISO 27001?

Answer: No. The company holds no ISO 27001 certification.

Evidence: Company certification record in this document, dated Oct 27, 2026.

Detail: The answer is a plain no. No ISO 27001 certificate, scope statement, certification body, or validity date is claimed. The founder credentials in H4 are personal credentials, not a company ISO 27001 certification, and they are not presented as one. A buyer who needs ISO 27001 assurance should require a certificate and scope that can be checked, and this document does not offer one.

Related: Trust Center Documents section; H1; H3; H4.

Status: Answered not held

H3. Does the company hold ISO 42001 or any other company certification?

Answer: No. The company holds no ISO 42001 certification and no other company certification.

Evidence: Company certification record in this document, dated Oct 27, 2026.

Detail: This answer covers the remainder of the company certification question, so a buyer does not need to ask it a second time for another standard. The scope is company certifications, not personal credentials and not registrations. Registrations in A5 are registrations, and founder credentials in H4 are personal, and neither is counted as a company certification here. If a company certification is gained in future, it should be added as a new dated entry with its scope and validity date, as a new dated entry, not backdated into this answer.

Related: Trust Center Documents section; A5; H1; H2; H4.

Status: Answered not held

H4. What credentials does the founder hold?

Answer: The founder holds ISC2 CC, CIPP/C, and Lean Six Sigma coursework (LinkedIn Learning, 2022). These are personal credentials only.

Evidence: Founder credentials record in this document, dated Oct 27, 2026. The date of each credential is not stated in this document.

Detail: Each credential is named, and the personal-only limit is stated in the same answer, so the credentials cannot be misread as company certifications. ISC2 CC and CIPP/C are relevant to security and privacy work, and Lean Six Sigma coursework is relevant to process work, but relevance is not the same as a company certification, an audit, or a client outcome. No credential number or issuer detail beyond the credential name is added here, because none is stated in the evidence stated in this document. A buyer who needs credential verification should ask for it as a tailored response, using the route in Section 15.

Related: Trust Center Documents section; A4; H1; H2; H3; L1.

Status: Answered with evidence

H5. Does the company hold insurance?

Answer: No insurance is held or claimed in this document.

Evidence: No insurance record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: No policy type, insurer, limit, or validity period is stated, because none is held or claimed in the record in this document. This matters for procurement: a buyer who needs insurance, for example professional liability or cyber cover, must require it in writing per engagement, before work starts, with the type and limit named in the written terms. Until such a requirement is met and recorded, a buyer should not assume cover exists. Clearance is covered separately in L4, where the same plain position applies.

Related: Trust Center Documents section; L4; L5.

Category I: Privacy and regulation

Legal scope note for this category: The services below are advisory services. They help a client understand and meet its own obligations. They are not certifications, they are not client outcomes, and they do not give legal advice for a specific client matter. A client's own legal position for a specific matter must be confirmed in writing per engagement, with the client's own counsel where the client needs it.

Status: Answered not held

I1. What Law 25 compliance support is offered?

Answer: Law 25 compliance support is offered as an advisory service.

Evidence: Service record in this document, dated Oct 27, 2026. Site in scope: https://movahedi.ca

Detail: Law 25 here means Quebec's privacy law reform work, approached as a compliance support service: mapping obligations, reviewing practices and materials, and helping a client plan its compliance steps. The service is the support, not a Law 25 certification, because no such company certification is claimed in H3. No client outcome under Law 25 is claimed from listing the service, and no client name is attached to it. The scope, the materials reviewed, and the deliverable for a specific client must be confirmed in writing per engagement, before work starts, so the client knows what the support covers and what it does not cover.

Related: Trust Center Documents section; A2; I4; L5.

Status: Answered with evidence

I2. What EU AI Act readiness work is offered?

Answer: EU AI Act readiness work is offered as part of the AI Governance service, as an advisory service.

Evidence: Service record in this document, dated Oct 27, 2026. Site in scope: https://movahedi.ca

Detail: Readiness assessment means assessing how ready a client's AI use is against EU AI Act expectations, as an advisory exercise. It is not an EU AI Act certification, it is not a conformity assessment by a notified body, and it is not a client outcome. No client outcome under the EU AI Act is claimed from listing the service, and no client name is attached to it. The pattern of the work is inventory and risk analysis: listing AI and agent uses, mapping them to risk and governance expectations, and producing a readiness assessment with gaps and next steps. That pattern is stated in general terms only. The scope and the deliverable for a specific client must be confirmed in writing per engagement, before work starts.

Related: Trust Center Documents section; A2; I1; I4; J2.

Status: Answered with evidence

I3. What privacy policy governs the public site?

Answer: The Privacy Policy for movahedi.ca, last updated October 29, 2026.

Evidence: Privacy Policy record, last updated October 29, 2026. Site: https://movahedi.ca

Detail: The policy date is the evidence, and it is not moved forward to match this questionnaire. A buyer reading this questionnaire on Oct 27-29, 2026 therefore sees a policy dated October 29, 2026, which is the correct dated position. The policy governs the public site, not engagement material, which is governed by the engagement rules in Category B and the written terms for that engagement. If the policy is updated, the new date should be recorded as a new dated entry, with the old date kept in the change record, not overwritten without trace.

Related: Privacy Policy; Trust Center Documents section; B1; B2; I4.

Status: Answered with evidence

I4. Does the vendor claim general compliance with privacy laws such as PIPEDA or GDPR?

Answer: No general compliance claim is made in this document. The compliance position for a specific engagement must be confirmed in writing per engagement.

Evidence: No general compliance claim record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Privacy compliance depends on the data, the purpose, the jurisdiction, and the roles of the parties in a specific engagement. A blanket claim covering every law and every engagement would hide those variables, so none is made. Instead, the services in I1 and I2 are offered as support and assessment, the client data rules in Category B set the default handling position, and the specific compliance position, including roles, lawful basis or authority where relevant, transfer rules, and notification duties, must be set in writing for that engagement, before material is shared. A client that needs a legal position for its own matter should confirm it with its own counsel as part of that written confirmation.

Related: Privacy Policy; B4; G3; I1; I2; L5.

Status: Answered to be confirmed in writing per engagement

I5. Are client materials sold, used for training, or named publicly?

Answer: No. Client material is not sold, it is not used for model training, and no client is named publicly without written permission.

Evidence: Client data rules record in this document, dated Oct 27, 2026.

Detail: Three separate prohibitions are stated, and each stands on its own. No sale covers transfer for value to an unrelated party. No model training use covers the vendor's own models and third party models alike. No public naming without written permission covers case studies, client lists, logos, testimonials, and any other public naming. Written permission is the only exception stated for public naming, and it must be permission for that specific naming, not a general engagement signature read as naming consent. No client is named anywhere in this document, and no testimonial or logo is included, consistent with this rule.

Related: Trust Center Documents section; B2; B5; J5; L5.

Category J: Subprocessors and third parties

Status: Answered with evidence

J1. Which third parties deliver the public site?

Answer: For the public site, infrastructure and edge delivery run on Cloudflare (including Cloudflare Pages and Workers) and GitHub (source and build). Depending on the feature you use, the site also uses Google (Gemini Flash model family via Google AI Studio for the Ask widget; Google Workspace for email; consent-gated Google Analytics), Cloudflare Workers AI (Ask widget fallback), Microsoft Clarity (consent-gated analytics), MailerLite (newsletter opt-in and delivery), and Cal.com (discovery call scheduling). Full details are in the Website Privacy Policy.

Evidence: Technology record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: These providers form the delivery and feature chain for the public site, and they are named because a buyer assessing the site needs to know the chain. No plan tier is claimed for any provider, as stated in D2. No client data sits on the public site under B1, so the delivery chain for the public site is not a client data processing chain. Engagement tools are a separate matter and are covered in J2, where per-engagement confirmation applies.

Related: Trust Center Security Practices section; D1; D2; F1; J2.

Status: Answered with evidence

J2. Which third parties will handle client engagement material?

Answer: No engagement third party list is stated generally in this document. Any third party that will handle engagement material must be confirmed in writing per engagement.

Evidence: No engagement third party list is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Engagement tools can vary by engagement: a shared folder, a review tool, a research source, or a delivery channel agreed for that engagement. Because the list varies, a general list stated here would be wrong for at least some engagements. The correct position is a per-engagement list, agreed in writing before material is shared, naming each third party, what it will handle, and for what purpose. If no third party will handle the material, that too should be stated in the written terms for that engagement, so the absence is recorded rather than assumed.

Related: Trust Center Documents section; B2; C1; D3; J3; J5.

Status: Answered to be confirmed in writing per engagement

J3. How will a client be told about a change to an engagement third party?

Answer: No change notice rule is stated generally in this document. The notice rule for an engagement must be confirmed in writing per engagement.

Evidence: No change notice record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: A change to a third party can change risk, residency, or access, so a buyer needs to know in advance how a change will be communicated and whether approval is needed before the change takes effect. That rule depends on the engagement, so it belongs in the written terms for that engagement, before work starts. The written rule should cover what counts as a change, how notice is given, how much notice is given, and whether the client can object. No notice period in days is stated here, because none is verified generally in the evidence stated in this document.

Related: Trust Center Documents section; J2; J5; L5.

Status: Answered to be confirmed in writing per engagement

J4. Is there a published vendor assessment process for third parties?

Answer: No published vendor assessment process is claimed in this document.

Evidence: No vendor assessment process record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Evidence for this answer is limited to the items stated below. The delivery providers for the public site are named in J1, and engagement third parties are confirmed per engagement in J2, but a documented assessment process, with criteria, review steps, and records, is not claimed. A buyer who needs such a process should require it in writing for the relevant scope, with criteria and records agreed before a third party handles material. Until that process exists and is recorded, this answer stays not held.

Related: Trust Center Security Practices section; J1; J2; J3.

Status: Answered not held

J5. Is client material shared with third parties beyond the engagement?

Answer: No. Client material is used only for its engagement, it is not sold, and it is not shared for an unrelated purpose.

Evidence: Client data rules record in this document, dated Oct 27, 2026.

Detail: This answer restates the B2 use limit from the sharing angle, so a buyer reading only this category still gets the limit. Sharing within an engagement, to a third party agreed in writing under J2, is different from sharing beyond the engagement, and only the first is possible under this rule, and only where the written terms allow it. Sharing beyond the engagement, for marketing, for another client, for sale, or for training, is not allowed under B2 and I5. No third party beyond the engagement is named as a recipient anywhere in this document.

Related: Trust Center Documents section; B2; I5; J2; J3.

Category K: Business continuity and availability

Status: Answered with evidence

K1. What uptime service level is offered for movahedi.ca or for engagement work?

Answer: No uptime service level is claimed in this document.

Evidence: No service level record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: No percentage, no measurement period, and no credit or remedy is stated, because none is held or claimed in the record in this document. The public site is live, as stated in K5, but live today is not an uptime promise for tomorrow, and it is not presented as one. A buyer who needs an availability commitment for a specific service or engagement must require it in writing, with the service, the measurement, and the remedy named, before work starts. Until that commitment exists, this answer stays not held.

Related: Trust Center Documents section; E5; K5; L5.

Status: Answered not held

K2. What recovery time and recovery point objectives apply?

Answer: No recovery time objective and no recovery point objective is stated in this document. Both must be confirmed in writing per engagement where they are needed.

Evidence: No recovery objective record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Recovery objectives are numbers with consequences: a time to restore, and a point in time to restore to. Stating them generally, without a service scope and without a tested recovery record, would give a buyer numbers with no way to check them. For the public site, the rebuild-from-source pattern in F1 is stated, but no time objective is drawn from it. For engagement material, recovery depends on the tools and terms for that engagement, and any objective must be agreed in writing for that engagement, before material is shared.

Related: Trust Center Documents section; F1; F5; K3; K4.

Status: Answered to be confirmed in writing per engagement

K3. Is there a formal business continuity plan?

Answer: No formal business continuity plan is claimed in this document.

Evidence: No business continuity plan record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Evidence for this answer is limited to the items stated below. The public site rebuild pattern in F1 and the engagement removal rule in B5 are stated, but neither is presented as a formal business continuity plan. A formal plan would name continuity risks, alternate arrangements, roles, and review steps. None of those plan elements is stated generally here. A buyer who needs a plan should require it in writing for the relevant scope, before work starts, rather than treating the rebuild pattern alone as a plan.

Related: Trust Center Documents section; F1; K2; K4.

Status: Answered not held

K4. Has disaster recovery been tested?

Answer: No disaster recovery test is claimed in this document.

Evidence: No recovery test record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Testing recovery and being able to rebuild from source are different things, and the answer keeps them separate. F1 states the rebuild pattern for the public site. This answer adds that no test date, test scope, test result, or retest record is claimed for disaster recovery. A buyer who needs a tested recovery position should require the test in writing, with date, scope, and result, for the relevant scope. Until that record exists, this answer stays not held, and no test date is invented to fill it.

Related: Trust Center Documents section; F1; F5; K2; K3; G5.

Status: Answered not held

K5. Is movahedi.ca currently live?

Answer: Yes. The site is a live public site, as recorded in this document on Oct 27-29, 2026.

Evidence: Site record in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: Live status is stated as a dated observation, not as an availability promise. It means a buyer can check the site at the link given and see the public site that this questionnaire describes. It does not carry an uptime figure, a service level figure, or a future availability promise, and none is added here, consistent with K1. If the site moves, changes provider, or changes scope, the dated record should be updated with the change dated, not silently overwritten.

Related: Trust Center Documents section; D1; E1; E2; K1.

Category L: People, physical security, and contract terms

Status: Answered with evidence

L1. What screening applies to people who will access client material?

Answer: No screening claim is made in this document.

Evidence: No screening record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Screening is a specific commitment: a check type, a scope, and a point in time. No check type is stated here, because none is verified in the evidence stated in this document. Founder credentials in H4 are credentials, not screening checks, and they are not presented as screening. A buyer who needs screening, for example a background check or a reference check for people who will access its material, must require it in writing per engagement, before access is granted, naming the check and the people it covers. That written requirement is where A4, C1, and this answer meet: staffing, access, and screening are confirmed together, before work starts.

Related: Trust Center Documents section; A4; C1; H4; L5.

Status: Answered not held

L2. What security training is given to staff?

Answer: No security training claim is made in this document.

Evidence: No training record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: Evidence for this answer is limited to the items stated below. Personal credentials in H4 show personal qualifications, but they are not a training programme, and they are not presented as one. No training topic, frequency, attendance record, or completion rate is stated, because none is verified in the evidence stated in this document. A buyer who needs training for people who will work on its engagement should require it in writing per engagement, naming the training and the people it covers, before work starts.

Related: Trust Center Documents section; A4; H4; L1.

Status: Answered not held

L3. What physical security applies to a vendor facility holding client data?

Answer: No facility physical security claim applies, because no vendor facility holding client data is claimed.

Evidence: Site and service scope records in this document, dated Oct 27-29, 2026. Site: https://movahedi.ca

Detail: Physical security questions assume a facility, a data centre, or an office store holding client records. That model does not fit this vendor: the public site holds no client data under B1, engagement work is advisory, and no data centre or client data store facility is claimed. A buyer assessing physical security for a hosted data store should not use this answer, because no such store is claimed. Engagement material protection is covered instead by the use limits in Category B, the access limits in Category C, and the per-engagement confirmations in this document.

Related: Trust Center Security Practices section; B1; D5; J1.

Status: Answered not applicable

L4. Does the vendor hold a security clearance?

Answer: No. No security clearance is held or claimed in this document.

Evidence: No clearance record is stated in the evidence stated in this document, dated Oct 27, 2026.

Detail: The answer is a plain no, with no level, no issuing body, and no validity date added, because none exists in the record in this document. Registrations in A5 are registrations, not clearances, and they are not presented as clearances. Founder credentials in H4 are personal credentials, not clearances, and they are not presented as clearances. A buyer who needs a clearance for specific work must require it in writing per engagement, before work starts, naming the level and the people it must cover. Until such a requirement is met and recorded, a buyer should not assume clearance exists.

Related: Trust Center Documents section; A5; H4; H5; L5.

Status: Answered not held

L5. How are specific security, screening, or insurance requirements agreed for an engagement?

Answer: They are confirmed in writing per engagement, before work starts, using the contact route mohammad@movahedi.ca.

Evidence: Contract route record in this document, dated Oct 27, 2026. Contact: mohammad@movahedi.ca

Detail: This answer is the closing rule for the whole questionnaire, and it is stated as evidence because the route and the timing rule are both stated generally in this document. Specific security requirements, screening requirements, and insurance requirements are not general claims in this questionnaire: security requirements that depend on an engagement are in C2, C3, C4, and D3; screening is in L1; insurance is in H5; clearance is in L4. Each of those answers points to this written confirmation step. The confirmation must name the requirement, the scope, and the people or material it covers, so it can be checked after work starts. A requirement that is not confirmed in writing for that engagement should not be assumed to apply to that engagement.

Related: Trust Center Documents section; A3; B3; B4; C2; H5; L1; L4; Section 15.

15. Request route for a tailored response

To request a tailored response to a specific questionnaire, a fresh confirmation for a single entry, or written confirmation for a specific engagement, contact mohammad@movahedi.ca.

In the request, state:

1. The question number from this questionnaire, for example B3, G3, or J2, or the new question in full.
2. The engagement scope the question covers, where it covers an engagement.
3. The specific commitment needed, for example a retention period, a notification timetable, a screening check, an insurance type and limit, or a clearance level.
4. The date by which a written confirmation is needed, where a date applies.

A tailored response will be given as a dated, written confirmation for that request. It will not change the general answers in this questionnaire by implication. If a tailored confirmation differs from a general answer for a specific engagement, the tailored written confirmation governs that engagement, and the change will be recorded as a dated entry.

Related pages

• Trust Center
• Documents
• Security Questionnaire Answers
• Vendor Security Questionnaire
• Self-Assessments

Scope and limits, stated briefly

Where a matter is to be confirmed per engagement, it is stated as such, and it is confirmed in writing for that engagement before work starts. Contact: mohammad@movahedi.ca.