In point order:

1. Have some sort of standard video chat such as Zoom, etc to hold meetings easily. Importantly, everyone should have access so expensive tools like WebEx may not be what you're looking for. Additionally you'll probably want an asyncronous chat client. This can be Slack/ Microsoft Teams/ Mattermost/IRC etc, but there should be an easy way to ask questions async.

2. Plan out something so that new hires can easily meet the team. We personally assign new hires buddies and we also use a slack app called donut to randomly assign people to have coffee/tea/lunch together.

3. In terms of equipment, you'll probably be shipping laptops or something similar. MacOSX and Windows both support MDM client workflows so that a new hire opens up the computer and it autoinstalls your company's standard tools, and enforces secure configurations (search for Zero touch deployments for more info). This should definitely include encrypting the laptop as lost/stolen laptops can be considered a data breach if they are not encrypted. Note that some companies still have larger than normal laptop processing times to ship out equipment.

4. In terms of restrictions for what new employees can access, you'll usually grant access to all of the codebase but give more limited permissions to access secrets (this assumes that you have a separate secret management tool and your keys aren't in plaintext so your milage may vary). This is often controlled by role-based access control (RBAC)

5. In terms of ramping up someone's access what you're looking for is attribute-based access control (ABAC), where you can create fancy-pants rules like grant access to X when someone has been at the company for 3 months. At 40ish engineers, you're probably not there, but this should be something you're asking about when IAM comes up and when you're hiring more traditional IT or security folks. You _can_ also build out approval workflows, but these definitely slow down velocity and are more typical of larger corporations. This can significantly slow down development while not really providing much security benefit.

6. Re: legal/regulatory/cultural issues: Being based in Berlin, you have some EU laws around data usage ie EU-US Data Shield and GDPR considerations. Besides that, you'll probably need to check with your company lawyers. Per devs stealing equipment, your finance team probably doesn't care if a hire steals a laptop or other equipment (That laptop is probably values as less than 1000 euros. Time spent trying to recover it will probably outweigh the value of the equipment). If someone steals valuable data or IP, especially if you need to report a security breach, that is a different story. You _can_ still call the police in that location. As you grow, insider threats could become a bigger danger. Most security compliance frameworks (NIST/ISO/etc) require building out controls for insider threats including at a minimum audit logs etc. At 40ish engineers this is not a big concern since your interview process should hopefully be weeding out problems.

7. The biggest issue with going remote is all those things that you currently do in person that compose your companies tribal knowledge. Meetings, how things work, how to best configure your editor and dev environment. You may have existing documentation, but you'll likely need to invest time in improving it. Do you take meeting notes and are those available to read by your engineering team?