Security is
not first and foremost a technical problem. It is a resource attribution problem. That is the most important thing to understand about security.
It is a resource problem because security is only a cost that is used to hedge against the possibility of future losses which means there is always alignment towards a minimum possible investment in security.
This means a security person's primary purpose is to first estimate the cost of a security breach and then lobby for appropriate resources. Listing out the ways security can fail and associating a cost for each is vastly more important than the technical work of security itself.
You are that minimum investment, so you are the security scapegoat when things go wrong. You need to make sure that responsibility for security failure is always associated with your management because ultimately they control the resources applied to security. If management is not able or willing to hire a security expert who can speak authoritatively on the topic, that is on management, that is not on you.
From a technical perspective:
Security can be divided into ~3 major areas. Corp security, infra security, product security (later on incident response, fraud/abuse, and internal pen testing).
Corp security is sufficiently complicated that it probably needs to be a hat worn by the person administrating employee computers until a person devoted to corporate security (or internal administration) can be hired. The attack surface of corporate networks is too large to be handled by one person. This means whoever manages account creation for corporate e-mail or whoever purchases hardware on behalf of the company for employees needs to be responsible for security of said accounts, that employees computers are reasonably monitored and secure, and that phishing is generally not a fruitful endeavor.
Infra and product security are inter-related enough that one person can wear that hat for a while. Absolutely set up a bug bounty program. Lots of links here seem reasonable for hardening or understanding attacks.
Inventory the valuable things your company has. Customer data? Build signing keys? Encryption keys? Business bank account? Internal communications? Keeping an inventory of the things an attacker would want is first.
After developing your threat model, define your border. What is the ingress and egress to all of your systems. What has a public IP? What services listen externally? What websites does your company have accounts with? This is your attack surface.
Once you have defined what can be taken, how much damage it will cause, and the attack surface you need to secure, you are ready to have a conversation about appropriate investment in security. Then you can worry about hardening/defense and then you can worry about defense in depth.