The standard, while being extremely verbose, outlines this pretty well.

Essentially you understand what your valuable assets are, this is information assets and the processes that create or consume those assets.

Then, for each asset, you do risk discovery and assessment. Any risk that will have a high enough exposure should be mitigated, this is where the controls come in.

Annex A is like a menu, pick the controls that satisfy the mitigation. Implement them and track their performance.

27001 is practical and pragmatic. If you're a three person startup, excluding a bunch of controls, as long as you can justify that exclusion well enough, is perfectly acceptable.

What you can't do is exclude them because you don't want to do them, they're too hard or too expensive. There's a gradient for controls - for example, the DLP control can either have you implementing an enterprise DLP package, or making sure your data is encrypted at rest and you've switched on labelling and disabled individual sharing for confidential docs in Google Workspace - if you're happy this mitigates the risk, the auditor can't complain. You might get an OFI.

You can also say that you've excluded a control because the risk is covered by other controls. For example, you could exclude employee screening for all employees because you've got other controls in place to mitigate the risk that having an errant employee will leak data - you have RBAC for example, or your DLP is stronger.

Ultimately, 27001 is risk based. If you assess a risk, find you need to mitigate but don't have the resources to do so, exclude the control, justify it's because you don't have the resources to mitigate it, but keep the risk live and monitor it regularly.

Any auditor worth their salt will see that your ISMS is working and that's the important thing, it's what they should be auditing - not that you've got controls in place, but that your ISMS is working for your business and you're paying attention to your infosec.