Complete newbie here - where to start with a basic ISO 27001 project?

I am beginning an ISO 27001 implementation project for my organization and will be using Hyperproof as our GRC platform. My background is in data science, not compliance, so I am approaching this as a structured problem requiring a clear initial dataset and methodology.

Based on preliminary reading of the standard (ISO/IEC 27001:2022 Annex A) and Hyperproof's own documentation, I have identified what I believe are the foundational components. I would appreciate a review from experienced users to validate my starting plan and point out any early missteps.

My proposed first-phase workflow within Hyperproof is:

* **Control Set Configuration:** Load the ISO 27001:2022 Annex A controls into a new Hyperproof program. I intend to use the pre-built template but will need to map our organizational context (scope, assets) to these controls.
* **Evidence Repository Structure:** Create a logical folder hierarchy for documentation (e.g., `/Scope/`, `/Risk-Assessments/`, `/Policies/`, `/Evidence/By-Control/`). Is there a conventional best practice for this within the platform?
* **Initial Risk Assessment:** Utilize the built-in risk register to catalog information assets and perform a basic inherent risk assessment. My primary uncertainty here is the granularity—should assets be defined at the system level (e.g., "AWS Production Environment") or the data level (e.g., "Customer PII Dataset")?

My key questions for the community are:

1. From a Hyperproof-specific standpoint, what are the most common configuration errors made during the initial program setup that hinder progress later during audit?
2. Are there particular Hyperproof features (like the "Requests" function or specific report types) that are critical for the early stages of evidence collection and stakeholder communication?
3. Given my statistical background, I am comfortable with risk scoring methodologies. However, I am unsure how to best leverage Hyperproof's quantitative fields versus its qualitative descriptors. Is there an advantage to using numeric likelihood/impact scales over the default "Low/Medium/High" for a first-time project?

I am particularly interested in any parallels between model evaluation frameworks in ML (where we track metrics, parameters, and results) and compliance program management. It seems like a similar exercise in traceability and evidence-based justification.